On 9/2/13 11:06 AM, sebb wrote: > 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.
If we want to go in this direction we should think about a new installer that can handle updates as well. But we should keep app stores of modern operating systems in mind as well. I still would love to see AOO in the Apple App Store in the future and the Windows App Store. Juergen >> >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
