Jeroen De Dauw wrote:
Would it not be enough to hash all extensions on the distributor side, and to check the hash sum on the client side using https for the connection?
I guess this would suffice for ensuring integrity, but what about the other distribution meta-data? Where to get it from, how to manipulate it, and how to format it? Since WP and PEAR have systems that do (now) well at that, it makes a lot more sense to just copy what they do instead of trying to re-invent the wheel and make all the same mistakes they did.
I would make the system based on our repository. So the MediaWiki update subsystem would have a base url like http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_16/
Then it would fetch a file called http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_14/VERSIONS containing all the extensions, their version and an optional url. If the version is newer than the installed one, it needs updating.
The presence of a special tag on the file for a url would send it to a new major version: http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_15/VERSIONS which would be recursed to the latest mediawiki branch so it can offer the really latest one for download (but note that it shouldn't use extensions from a newer branch without updating mediawiki).
If an extension doens't provide a url, treat it as extensions/<extension name> with a fallback to eg. extensions/archive/extensions/<extension name>.php (so we can safely redirect old extensions to new ones, etc.)
The VERSIONS file can be easily generated by an script reading their $wgExtensionCredits. Releasing a new extension would be increasing its version and recreating the VERSIONS file. Whereas if you the version isn't changed, new uploads would still get the improvements (yes, this scheme would also work for trunk).
To get an extension there, third party extension creators could request subversion access and place their extension there (the best option imho, since then they can be noticed when doing changes in core), get a developer to list their external url, or instruct the users to add their own repository to the repo list.