The vast majority of our downloads come from one of three pages: 1) www.openoffice.org/ 2) download.openoffice.org/ 3) www.openoffice.org/download/other.html
These three pages currently forward download requests to SourceForge. There are other places on the website that do other things. For example, the Dutch and Norwegian pages point directly to MirrorBrain downloads: http://www.openoffice.org/da/ http://www.openoffice.org/no/ http://www.openoffice.org/es/ (There may be others as well, but I noticed those three) Other ML pages do other things. For example, the German page just points to download.openoffice.org, where the user is given the English install instructions: http://www.openoffice.org/de/ The French page manages its own download page that directs to download.services.openoffice.org, which uses MirrorBrain: http://www.openoffice.org/fr/Telecharger/ To put it kindly, the logic here is sub-optimally factored. Is there anything we can do to improve on this? For example, imagine if we had either a Javascript function or REST API that allowed things like this: download(product,language, platform, version) Like: download("aoo","en_us","win32","3.4.0") or download("sdk","","","latest") (We could allow "latest" as a psedu-version number so most NL pages can code their download logic once and not need to update it when a new release comes out. We centralize the logic of what is the "latest" version for a particular language in one place) As a REST API the same could look like this: http://www.openoffice.org/download?product=aoo&locale=en_us&platform=win32&version=-3.4.0 Does this make sense to anyone? It all about avoiding have the website make too many assumptions about release file names, mirror infrastructure and other implementation details of the download delivery process. Instead we should have a centralized place where that logic lives, so it can be maintained in one place, debugged in one place, and when we have a new release, updated in one place. -Rob
