From Apache OpenOffice Wiki
Revision as of 12:18, 4 July 2008 by Floeff (Talk | contribs)

Jump to: navigation, search

What is bouncer? bouncer is the main-distribution platform for downloads. It is an open-source project of the Oregon state university. The current version of bouncer is 2. Some other major open-source projects use bouncer, e.g. uses bouncer in version 1.

Main difference between version 1 and 2 is:

  • Version 1 supports GeoIP (explained below) - written in Perl
  • Version 2 supports template mechanisms to get download-sets (required for - written in Python

Main reasons to adapt bouncer

Some of these named reasons are required to use bouncer in the future, others are optional. We try to adress some of these topics in the near future. Help is very welcome!

Geographical preselection of mirrors depending on IP, aka. GeoIP

Dispatching requests of downloading files from both users via web page and automatic download functionality implemented in (aka as product-update-service) to one of the mirror servers depending on the type of requested file and the location of the requester.

This is extremely important for countries with low IT resources and/or very unreliable/slow connections (e.g. Vietnam). It can take several days to download an build in Vietnam, and many people give up on the process. In any case, being assigned a download from a mirror on a different continent is noticeably inefficient. Users don't appreciate inefficiency.

Supporting extended mirrors for large volumes is available in many languages on many platforms and needs space for download-sets. The current mirroring has reached limits and need to be extended. The current version 2 doesn't support extended mirror-sets with large-volumes.

This would also allow us to provide full builds for the newer localizations reaching full-release mass (80% interface and Help). We continue to add localizations, which is a huge advantage for, but we need extra capacity to host these additional localized builds.

Failed requests should offer alternative downloads

Not all languages provide a complete set of platforms and os for a version. To avoid failures in the download-request we should allow offering alternative downloads. E.g. customer requests Danish 2.4.1 for Windows with JRE but we have only a version without JRE. So we should offer Dansih for Windows without JRE or in harder cases we use a standard default for en-US for all other languages as fallback.

SOAP interface to get distributions-status, useful for automated one-click-download

When we try to automate the distribution-process it would be helpful to get the download-status of an productivity suite.

We need this both for the Bouncer downloads, and for the native-language project download pages. These native-language download pages are used predominantly for testing pre-release builds, but many people prefer to download these updated builds (usually with an enhanced localization), rather than the last stable release. So both sources of statistics are significant.

Same user-account for OOo-Bouncer as OOo-IssueZilla

It would be nice to use the same account for like on IssueZilla.

A single-account login (unified sign-on) is one aim of the current ESC Dashboard effort. It makes sense for us all to work towards this efficiency measure, rather than creating further obstacles for it. We can already use our main login for tools like the Issue Tracker, EIS, QATrack and Pootle. Let's add Bouncer to our single-login toolbox.

SSL for log-in

Security issue to use http directly for log-in.

Anyone with source-control access is already using SSH/SSL, so it's a sensible security-measure which uses common FLOSS tools.

Better logging and statistics

Logstats only allow counting requests for version and platform. Failed requests won't be ignored, so the number of downloads is too high.

Failed downloads are bad PR for The builds are already discouragingly large, and we can't count on users knowing how to use curl, or necessarily using a download manager or browser with an effective resume function.

Many users will give up after the first failed download. We need to know when this is happening. It would also be useful to know how many download attempts, on the average, are necessary for different geographical locations and/or systems. We would need to combine these stats with the CD/DVD uptake stats (especially for regions where the low quality of Net connections makes install via CD/DVD preferable).

The more we know, the better use we can make of our resources. :)

User-friendlier download URLs

Using Apache's mod_rewrite or similar functionality, it should be possible to generate user-friendlier download URLs, like

Involved community members

Please add your email if you want to help us. Thank you very much.


Some other thoughts

  • only check "real" releases, other files won't need all the checks
  • or: only download random chunks of files to verify mirror
  • do load balancing between several Bouncer machines
  • rely on mirrors providing md5sum lists, maybe PGP signed, and verify these first, then check for files afterwards
  • we need better log files
Personal tools