On Monday, 23. April 2012 at 05:49, drew wrote: > On Sun, 2012-04-22 at 17:22 -0400, Rob Weir wrote: > > 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. > > > > Hi Rob > > Yes - it's not hard links to the mirrorbrain, other sub-domains I looked > at over the last few days use external repositories, one having not been > updated with releases from 3.2.1. > > If I may ask a question to the group in general: > > This page: > http://wiki.services.openoffice.org/wiki/Languages > > The list of email addresses, has anyone sent an email directly to each > entry asking them specifically if they have any interest in the page, or > any comment about what to do with it... maybe it is a waste of time, but > if not and no one objects I'd waste the time to do so. > >
please do so I would not expect that anybody has reached out them until now > > Otherwise, many of those sub-domains IMO need to be replaced with a > generic page pointing to a general how to get involved page. We need to > decide how to handle references to legacy releases also, particularly > those external links, do we keep a reference somewhere (the wiki maybe) > and for how long? > > I think I have mentioned this several times. I would prefer if we would have only general pages that get translated but all with consistent content. And every lang project can maintain either a subpage or from my pov better a wiki page Less pages with a cleaner structure, better and consistent content, translated and easier to maintain. Juergen > > Just a quick thought from reading your email, > > //drew
