incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juergen Schmidt <jogischm...@googlemail.com>
Subject Re: Unifying download logic, especially from NL pages?
Date Sun, 22 Apr 2012 22:24:41 GMT
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 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message