incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Unifying download logic, especially from NL pages?
Date Mon, 23 Apr 2012 17:09:23 GMT
On Mon, Apr 23, 2012 at 12:15 PM, Kay Schenk <kay.schenk@gmail.com> wrote:
>
>
> On 04/22/2012 02:22 PM, Rob Weir wrote:
>>
>> The vast majority of our downloads come from one of three pages:
>
>
> I offer a bit of historical perspective on these for what it's worth:
>
>>
>> 1) www.openoffice.org/
>
> -- the latest friendly action oriented page that grew out from the
> revised...(I can get everything I want from the home page.)
>
>> 2) download.openoffice.org/
>
> -- penultimate download page from a Download link. Incorporates same logic
> as DL button on home page. (One page click to DL)
>
>> 3) www.openoffice.org/download/other.html
>
> -- basically the original, original, download page which also incorproated
> information that couldn't be fit elsewhere. The user explicitly chooses the
> download without js logic assistance
>

OK.   I think these three pages are fine.  It is the NL pages that I
am concerned about, since they have hard-coded logic that differs from
the above pages.

>
>>
>> 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?
>
>
> maybe...is your concern about "policy" -- what pages can link to what
> download area, or
> implementation --- how is the appropriate download determined
>
> Could you elaborate a bit more?
>

For example, when we release AOO 3.4, we'll obviously update the logic
on the first three pages (www.openoffice.org, download.openoffice.org
and /other.html).  But any other NL pages that are hard-coded to point
to 3.3.0 downloads on MirrorBrain will not.

So not really a policy question, but a concern about how we partition
the logic in our website.  The NL pages should not need to know about
our release implementation details.  They should not be hardcoding
things like:

1) Names of release artifacts.

2) Assumptions about the most recent version of the product.

3) Assumptions about download locations.


>
>  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.
>
>
> So who or what would make those assumptions instead?
>

The Release Manager and the rest of the PMC determines these things
when we release.

>
>  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
>
>
> --
> ------------------------------------------------------------------------
> MzK
>
> "Women and cats will do as they please,
>  and men and dogs should relax and get used to the idea."
>                                    -- Robert Heinlein

Mime
View raw message