On 9/3/13 10:08 AM, Jürgen Schmidt wrote:
> On 9/3/13 6:40 AM, janI wrote:
>> On Sep 3, 2013 3:13 AM, "sebb" <seb...@gmail.com> wrote:
>>>
>>> On 2 September 2013 18:26, janI <j...@apache.org> wrote:
>>>> On 2 September 2013 15:48, Andrea Pescetti <pesce...@apache.org> wrote:
>>>>
>>>>> janI wrote:
>>>>>
>>>>>> Would it be possible (and preferable) to make a download page, where
>> the
>>>>>> user.
>>>>>> a) selected version (exe)
>>>>>> b) selected (multiple) languages (language pack without dictionary)
>>>>>> c) selected (mutiple) dictionaries.
>>>>>> The choices should be combined into a filename == exe+lang(s)+dict(s).
>>>>>> Which is sent to the server as a download request.
>>>>>> On the server we would have a backend script that packed the items
>>>>>> together
>>>>>> just like postprocess/instsetoo does today, so the user would get 1
>> file.
>>>>>>
>>>>>
>>>>> Obviously this is not for 4.0.1. What I like of this proposal is that
>> the
>>>>> user still downloads one file, which is optimal for the user interface.
>>>>>
>>>>> A beginning could be to simply assemble the same downloads we have now
>>>>> (i.e., the user has no choice: he will get, say, the Italian version
>> with
>>>>> Italian language and dictionary; only, this will be generated rather
>> than
>>>>> pre-built).
>>>>>
>>>>> Then there are a lot of things to consider:
>>>>>
>>>>> 1) Digital signatures: the assembled installer must respect them, and
>> this
>>>>> seems hard to do.
>>>>>
>>>> As far as I have been able to find out (with the good help of infra
>>>> colleagues) is:
>>>> - Only exe have a digital signature
>>>
>>> That does not sound right.
>>> All other ASF downloads (source archives, binary archives etc) have
>>> PGP signatures, which are created by the Release Manager.
>>>
>>> Or maybe you mean something else by "digital" signature?
>>
>> yes signing with a certificate. pgp is at level with mds/sha5.
> 
> we have *.asc, *.md5, *.sha256 for each released file, the binaries, the
> language packs, the src release, the SDK
> 
> And for Windows we have a self extracting exe file that can be installed
> with one click. Ok 1 click to start the install procesdure.

by the way with AOO 4.0.1 we will have additional languages.

If the ASF mirrors can't handle the binary release we have to rely on SF.

Don't get me wrong I would be happy to reduce the footprint of the files
but I don't see a solution quite fast and I don't see that anybody is
really working on it. We have so many other things to do that are more
important for the users.

Juergen

> 
> Juergen
> 
> 
>>
>>>
>>>> meaning this has no impact.
>>>>
>>>> But it DO have an impact on checksums, where we need to store all
>>>> combinations (lots of files, each very small).
>>>>
>>>>
>>>>>
>>>>> 2) Server-side processing: this would likely require some load on the
>>>>> mirrors and some infrastructure standardization. I don't know what's
>> the
>>>>> status on Apache mirrors.
>>>>>
>>>> The server side, processing would happen on "our" server, and the files
>>>> would still be located on the mirrors
>>>>
>>>> Basically the server side scropt, would "split" the file request into
>>>> multiple requests.
>>>
>>> If "our" server does the concatenation, surely it will have to
>>> intercept all the data from the mirror?
>>> That would put a huge network load on the server, no?
>> depending how you make it.
>>
>> rgds
>> jan i
>>>
>>>>
>>>>> 3) Respecting the priorities. Apache is a secondary mirror system,
>> since
>>>>> the Apache mirrors don't have enough space/bandwidth to reliably offer
>>>>> downloads. So whatever is done should not cause technical issues with
>> our
>>>>> primary mirror system (SourceForge), that never had space/bandwidth
>>>>> problems. Note that also the Apache Archives never reported problems
>> so far
>>>>> about the space needed to archive old/current releases.
>>>>>
>>>>
>>>> The problem is only partial the space itself, much more the size of each
>>>> release. With a distributed system (like suggested) we can independently
>>>> release language packs, and the user sees them as integrated in the main
>>>> AOO release.
>>>>
>>>> rgds
>>>> jan i.
>>>>
>>>>>
>>>>> Regards,
>>>>>   Andrea.
>>>>>
>>>>>
>>>>>
>> ------------------------------**------------------------------**---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>> dev-unsubscr...@openoffice.apache.org>
>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to