Return-Path: X-Original-To: apmail-openoffice-dev-archive@www.apache.org Delivered-To: apmail-openoffice-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 96CD61080E for ; Tue, 3 Sep 2013 08:09:32 +0000 (UTC) Received: (qmail 83477 invoked by uid 500); 3 Sep 2013 08:09:31 -0000 Delivered-To: apmail-openoffice-dev-archive@openoffice.apache.org Received: (qmail 83399 invoked by uid 500); 3 Sep 2013 08:09:30 -0000 Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openoffice.apache.org Delivered-To: mailing list dev@openoffice.apache.org Received: (qmail 83391 invoked by uid 99); 3 Sep 2013 08:09:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Sep 2013 08:09:29 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jogischmidt@gmail.com designates 209.85.214.51 as permitted sender) Received: from [209.85.214.51] (HELO mail-bk0-f51.google.com) (209.85.214.51) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Sep 2013 08:09:19 +0000 Received: by mail-bk0-f51.google.com with SMTP id mx10so1898650bkb.24 for ; Tue, 03 Sep 2013 01:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zh/Q5V8kzRenbZnkrs2cZwLg6eh9CaTRLDmZ4TVii7w=; b=xbikMPzzNM5TPfMQR0KS7ck0z2QpzGNjOawpsHDsX+vtqBSBnu21I0uUPsVUYYzx8d ES5fSA1e6OvayTf3074RIILDhD3VHHRYtOLm/wY5aRd3xiaKREoUjYBzq6RJ4UrRg+gU 5bw8QSo+czWpCdRJ70eenLYmMImSnjgGk/GBkY1TjwLecRWmxb5OaHDZN9AMyjbAWC5n v/QAbnDOfNV8kHRpeNSuW7rgaTJA4W9W7eZfNHjRKhIKfCCA1UkbttVxkvIUZbHGe0MH EhQwxarTJIpohUA0wiSGxFm3DEYTuoeJ/LV7BTADVEf2p3WMhPM9PBWASfe+UzfnlD5D xT6g== X-Received: by 10.204.121.201 with SMTP id i9mr20711740bkr.13.1378195739600; Tue, 03 Sep 2013 01:08:59 -0700 (PDT) Received: from [9.155.131.29] (deibp9eh1--blueice2n2.emea.ibm.com. [195.212.29.172]) by mx.google.com with ESMTPSA id nv4sm3805406bkb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Sep 2013 01:08:59 -0700 (PDT) Message-ID: <52259919.4010701@gmail.com> Date: Tue, 03 Sep 2013 10:08:57 +0200 From: =?ISO-8859-1?Q?J=FCrgen_Schmidt?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dev@openoffice.apache.org Subject: Re: [discussion] smaller footprint on dist. References: <52243A79.202@apache.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 9/3/13 6:40 AM, janI wrote: > On Sep 3, 2013 3:13 AM, "sebb" wrote: >> >> On 2 September 2013 18:26, janI wrote: >>> On 2 September 2013 15:48, Andrea Pescetti 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. 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-unsubscribe@openoffice.apache.org> >>>> For additional commands, e-mail: dev-help@openoffice.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org >> For additional commands, e-mail: dev-help@openoffice.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org For additional commands, e-mail: dev-help@openoffice.apache.org