Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAP-ksoh=RpH7T2YGvTAW69aO91YMEbL1POVHdp+CdHXm_CGO4A@mail.gmail.com>
References: 
 <CAP-ksohn_CCEixOcGJw+9gUE0+qhTMBERnZ=BCv9jMggEUyS0A@mail.gmail.com>
	<4F95803C.4060304@gmail.com>
	<CAP-ksoj9dR2nRx3HxMzWK-hR6rnwY8TKjR+-AZtz9nCkyZ9V2g@mail.gmail.com>
	<4F95A6DF.8050609@apache.org>
	<CAP-ksoh=RpH7T2YGvTAW69aO91YMEbL1POVHdp+CdHXm_CGO4A@mail.gmail.com>
Date: Mon, 23 Apr 2012 15:26:35 -0400
Message-ID: 
 <CAP-ksoixXe8xz1+dDKdD=2ZskcFkORmMUELLkvmkYhSOza5DhA@mail.gmail.com>
Subject: Re: Unifying download logic, especially from NL pages?
From: Rob Weir <robweir@apache.org>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 23, 2012 at 3:22 PM, Rob Weir <robweir@apache.org> wrote:
> On Mon, Apr 23, 2012 at 3:00 PM, Andrea Pescetti <pescetti@apache.org> wr=
ote:
>> Rob Weir wrote:
>>>
>>> It is the NL pages that I
>>> am concerned about, since they have hard-coded logic that differs from
>>> the above pages.
>>
>>
>> The Italian one is probably the worst at the moment, since it has hard-c=
oded
>> links (to the Italian mirror; this is a relatively recent change to avoi=
d
>> depending on the changing mirror situation), hard-coded version numbers =
in
>> the download page and even a hard-coded directory for the download page.
>>
>> While I see it changing (at the very least, the download link will be
>> pointing to the SF/MirroBrain URL and not to a specific mirror), I'm not
>> sure that the convenience of an API to generate links will always outwei=
gh
>> the added complexity: a link to the 'latest' version would have to be
>> changed, for example, if a version-specific security patch is released, =
like
>> it happened for 3.3.0.
>>
>
> I think the convenience will always outweigh. =C2=A0Remember, we can neve=
r
> reduce the real world complexity (essential complexity) any more than
> it is in the real world.
>
> All we can do are two things:
>
> 1) Put all of the real world complexity in one place so it can be
> centrally managed, updated, debugged, etc.
>
> 2) Reduce the accidental complexity
>
> Since the essential complexity can never exceed the total complexity,
> centralizing this logic will always be a net improvement.
>

(Sorry, unstated assumption I should make:  It is not true that all
users who want the Italian version will come through the Italian NL
page.  Therefore if there ever were some special rule that needed to
be defined for the Italian download, it would need to be triggered
from four different places:

1) Italian NL page

2) www.openoffice.org page

3) download.openoffice.org page

3) download.openoffice.org/other.html page

This would be very ugly.  So even in a world where you think there may
be special rules that apply to only a single NL, it still makes sense
to centralize that special rule into a centrally managed script.  That
reduces the net complexity of the system.)

> -Rob
>
>> Regards,
>> =C2=A0Andrea.