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. > > > 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 >
