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.