On Mon, 2012-04-23 at 16:39 -0400, Rob Weir wrote: > On Thu, Apr 19, 2012 at 9:57 PM, Mark Ramm <[email protected]> wrote: > >> A few ways, some worse than others: > >> > >> 1) Offer several download links: "Download from Apache, from > >> SourceForge, from MirrorBrain". Of course that doesn't balance the > >> load, but maybe it would if we randomized the order that they are > >> listed. > >> > >> 2) Have a single link, but it is JavaScript that then directs to one > >> of the three mirrors systems. This is easy to distribute the load > >> according to a defined schedule. Marcus prototyped an approach like > >> this. It looked like it was working. I'm not sure, however, whether > >> it handled fallbacks. For example, you randomly select to use the > >> Apache mirror, but the particular operator chosen is down. User > >> experience for backing out of that and repeating was as nice as it > >> could be. > >> > >> 3) Some variation on 3 where we handle the fallbacks better, or at > >> least handle failures better, so the user just needs to click again. > > > > I would be in favor of a forth option suggested by Andreas in another > > thread: > > > > * Route "autoupdater" traffic through one system (MirrorBrain) > > * Route web based traffic through another (SF as primary, and Apache > > mirrors as secondary) > > > > This eliminates potential problems with "which mirror network is > > having a problem" kinds of debugging which would be particularly > > pernicious if we randomized anything about the process. It also has > > the benefit of most closely matching Joe's original suggestion of how > > to use SF.net, and provides a clear accountability/support chain for > > users when downloads fail. > > > > SF.net will as previously mentioned provide an API to collect stats on > > downloads from our system, and we'd be happy to help host a bouncer > > that forwards requests to a MirrorBrain server so that updater stats > > can be collected as well if that helps the team measure the release > > download volume more effectively. > > > > Hi Mark, > > I like your idea. +1. > > First, it is simple and easy to implement. Second, we're in the > middle of our 3.4 Release Candidate vote and we don't have time to > implement, debug and tune something more complicated right now. > > We could be less than a week from release at this point. We've been > discussing AOO mirror for longer than that now. We've also been > running, successfully, with 3.3.0 downloads going through SourceForge > for longer than that. So I think it is time to stop designing the > next generation system (and I'm guilty as anyone for this) and move > forward with the stable download support we're going to need very soon > for AOO 3.4.
I agree for 3.4 and hopefully by 4.0 things will have worked out so that it is no longer necessary to give our traffic to a commercial operator. //drew > > -Rob > > > --Mark Ramm > > ==== > > This e- mail message is intended only for the named recipient(s) above. It > > may contain confidential and privileged information. If you are not the > > intended recipient you are hereby notified that any dissemination, > > distribution or copying of this e-mail and any attachment(s) is strictly > > prohibited. If you have received this e-mail in error, please immediately > > notify the sender by replying to this e-mail and delete the message and any > > attachment(s) from your system. Thank you. > > >
