The OpenOffice.org website project and the distribution project share the burden to provide our users and developers download pages without broken links. For some years we tracked our mirrors with mirmon and manually maintained a list of URLs for the JavaScript-driven download forms. With about 100 mirrors and files for 4 platforms, variations with and without JRE plus sources this is error-prone and certainly led to broken links.

Fortunately Oregon State University Open Source Lab ( osuosl) offered to host Bouncer for OpenOffice.org. Bouncer is a database driven mirror management application that has three main components - a bounce script, a sentry script to check mirrors and files for integrity and a set of web-based administration tools.
We are able to provide an URL for a file in download pages and bouncer takes care of the redirection to a mirror. Just add files with md5sums and bouncer ensures that the load is distributed according to mirror's weight. You'll never run into broken links. If it only were that easy...

For 2.1.0rc2 links using bouncer look like

http://openoffice.bouncer.osuosl.org/?product=OpenOffice.org&os=src_bzip&lang=src&version=2.1.0 RC2 http://openoffice.bouncer.osuosl.org/?product=OpenOffice.org&os=src&lang=system&version=2.1.0 RC2
for sources; splitted sources src-binfilter, src-l10n, src-sdk are formed accordingly. The language “src” equals to an empty string.

http://openoffice.bouncer.osuosl.org/?product=OpenOffice.org&os=linuxintel&lang=en-US&version=2.1.0 RC2
for installation sets; platforms macosxintel, macosxppc, solarisx86, solarissparc, win have been configured so far.

It starts to become interesting if localized builds are enhanced with a JRE or provided as debian packages and served from a path containing the locale ... The tricky part is the maintenance of full pathname templates for files related to a release. Those consist of fixed parts and placeholders for product, version, os, language and extension. The templates for 2.1.0rc2 look like

${mirror_baseurl}/contrib/rc/${pv_path}/\
 ${pv_product_short_name}_${pv_path}_20061201_${os_path}${lang_path}${os_extension}
${mirror_baseurl}/contrib/rc/${pv_path}/\
 ${pv_product_short_name}_${pv_path}_20061130_${os_path}_${lang_path}.${os_extension}
...

If you look at our file naming scheme you'll notice that we have to stretch the system a bit.

OOo(product name)_Version(incl. date stamp)\
 _OSCPU_what_locale(optional _wJRE).ext

But it wouldn't be too hard to press optional portions like wJRE and the date in the variable os_path of our fixed structure. Let's refrain from naming directories zn-TW but files zn-tw, Or was it vice versa? Splitted source tarballs can work also, if we give all pieces an additional “ locale” like sdk, core, ... Unfortunately you don't see immediately whether your changes work as intended. One has to check the status pages and wait for the next update cycle. Additionally access to the logfile of a mirror can tell you which URLs are requested.

We have to be consistent in our naming. Then it's just the upload of the md5sum file and all files are available for download with their respective URL as soon as some mirrors are ready. Joost, I'm sure you'll like it as soon as we have templates for all our file and release types in stock. Feel free to add localized builds on request of the NLC QA groups.

Let's see whether new versions will work for OpenOffice.org too now that Mike moved to Mozilla. There are some interesting features planned. Thanks Corey, Mike, ... for your support for OpenOffice.org and help.with bouncer.

Please allow me to point you to the OSL Rackathon: