Opened 9 years ago
#106 new enhancement
Move mod storage from Mod Depot to Subversion
Reported by: | Iritscen | Owned by: | Christian |
---|---|---|---|
Priority: | major | Component: | AEI2 |
Keywords: | Cc: |
Description
Benefits of svn over the Depot:
- No mandatory Depot maintenance (as we have seen, Drupal sites are major targets for hackers). Not only do Drupal updates require replacing the entire PHP installation with new files, but some aspects of the configuration of the Depot are fragile and a major update could break them.
- Mods in an svn repo would have unzipped Mod_Info.cfg files that could be read by the server or AE Installer, removing the need to duplicate a Mod_Info file's information on the mod's Depot page.
- svn will allow us to see precisely what is being changed by modders. Right now we can only see one ZIP of a mod being replaced by another, and the Depot cannot even send me notifications when a change is made.
Suggested method of operation:
- Modders would get accounts for a Subversion repo in place of their Depot accounts. Checking in changes to their mods should be easy with an svn GUI.
- When a modder updates his mod, a post-commit svn hook triggers a script that re-ZIPs the latest version of a mod folder in the repo, and updates a cache file with the new mod info.
- When the AEI reads the cache file and sees an update to an installed mod, it downloads the zipped version of the mod and expands it, as it does currently.
Open questions:
- What do we do with all the links to Depot mod pages that are out there? A URL rewrite rule could be created for each one, but where would it lead?
- Right now, someone without the AE installed can browse available mods on the Depot to get a sense of what's out there. Otherwise they have to go through a lengthy installation process before they can even see what is available (since reading raw Mod_Infos using WebSVN won't be any fun). How can we provide this info without the Depot?
- What do we do with non-package mods that can't be installed by the AEI? There are a decent number of these mods, and most of them cannot be ported to packages for various reasons, or they already would have been.
My suggested solution for all three points is that we make a simple PHP script for listing mods. When the main URL is accessed (say, mods.oni2.net), it lists all mods' names by category, and maybe shows their descriptions (this text can come from a cache constructed from the mods' Mod_Info files). At the top of the page would be a note explaining that the AE is needed to actually install these mods.
When a user attempts to follow an old Depot download link (to a mod page node), URL rewriting is used to pass the script the node number they asked for, and it matches that against a table that we prepare in advance that shows which URL was formerly used for which mod. Making this table would be a one-time operation. Using this node-to-svn-directory lookup table, the PHP script would read the current Mod_Info of the mod (or a cache thereof) and show the info for just that mod, with the same explanation about needing the AEI to download it.
This would allow non-package mods to also be committed to svn, but using a Mod_Info.cfg file that is intended for viewing solely on the re-purposed mods.oni2.net web site. This is the only way that modders can still have permission to update their mod pages after the Depot is taken away.