On 2 September 2013 09:33, Jürgen Schmidt <jogischm...@gmail.com> wrote: > On 9/2/13 12:55 AM, sebb wrote: >> On 1 September 2013 23:48, janI <j...@apache.org> wrote: >>> Hi. >>> >>> I am considering how we can have a smaller footprint on dist and mirrors. >>> >>> One of the ideas is to have a "pure" exe, "pure" language oxt and "pure" >>> dictionaries on the physical disk, and the have a more intelligent download >>> page. >>> >> >>> 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. >>> >>> I know how to make the backend script, but the UI could be a problem ? > > I think it is no new idea and the first question is how we handle the > signatures?
WIth the current build, the combined packages are created upfront and signed by the RM. Provided that the packages are put together in the same way from the same component parts, the sigs will still be valid. So the RM would still need to create the combined packages, but each could be junked after creating the sig. However one might want to keep them in a separate area for SourceForge which does seem to be able to handle the volume. Or indeed use the concatenation approach if that can be combined witrh rsync (or whatever SF uses to fetch the stuff). Obviously hashes can be created the same way. If a separate download / installer is used, the problem does not arise as the parts/sigs don't change. There's another issue with concatenation by the server: if this requires server configuration, then mirrors will have to do it as well. That may be a step too far. It would be technically possible to use a different strategy for the ASF mirrors as opposed to SF downloads. E.g. SF continues as now, ASF mirrors use two downloads or download/installer. Since the vast bulk of downloads are likely to be from SF, would that be practical? >> >> I just posted to a different thread much the same thoughts. >> >> Another way to solve UI issue might be to generate a (small) >> downloader in each language + OS combination and have that do the >> download. >> Though I've just realised that would not allow a download manager to >> be used for the main download(s). > > Again no new ideas and work for such a special downloader/instaler was > already ongoing in former times but never made it in the public repo. > > We should take some important points into account. One click > installation for end users is very important. > Offline distribution is also important for users with low bandwidth. > > Juergen > > >> >> >>> rgds >>> jan I. >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
