On Fri, Apr 20, 2012 at 6:06 PM, Kay Schenk <kay.sch...@gmail.com> wrote: > On Thu, Apr 19, 2012 at 7:36 PM, drew <d...@baseanswers.com> wrote: > >> On Thu, 2012-04-19 at 21:57 -0400, Mark Ramm 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. >> > > I'll take a look at what Marcus did. It is very easy to just do a "random" > link based on 3 mirror systems -- ASF, SourceForge, MirrorBrain. > > >> > > >> > > 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. >> > >> > > Yes, this is desirable -- but I think this would involve more server-side > intelligence or ajax programming instead of simple JS. I'd need to look > into it. Maybe beyond my capabilities. :/ > > > >> > I would be in favor of a forth option suggested by Andreas in another >> thread: >> > >> > * Route "autoupdater" traffic through one system (MirrorBrain) >> > > Ah yes...ye olde autoupdater. As of yet, I don't think we have nailed down > the "format" of the feed document for this. I could be wrong, but I haven't > seen anything from anyone -- maybe another separate thread on this is in > order. I tried several approaches to make this actually work, and nothing! > So, this makes sense but ????? I havent' forgotten about it, I just don't > know what to do about it. We need very specific details on constructing the > atom feed and then, of course, constructing it. > > >> > * Route web based traffic through another (SF as primary, and Apache >> > mirrors as secondary) >> >> Well, that sure looks like to most sane way to go from what I've seen >> described - seems the cleanest way. >> >> //drew >> >> > OK, in summary -- I'll take a look at what Marcus has already done -- and > get a prototype "simple" random selection DL script out there early on next > week for additional comments. >
It looks like we need to worry about three things: legacy downloads, AOO 3.4 downloads and OOo 3.3 upgrades. So how about something like this: 1) Legacy downloads (OOo 3.3.0 and earlier) are distributed only via MirrorBrain 2) AOO 3,4 release goes to SourceForge and Apache for download, with random selection and a splitting ratio that we can tune in the script. The script Marcus started is a good start, This allows us to gain some experience working with all three networks, see how they perform, get user feedback,etc, before tackling the upgrades. Then 3) When we are ready to turn on the automatic updates for 3.3.0->3.4.0, then we make a choice based on what we've learned by doing 1) and 2). In other words, don't worry about the update downloads until later, based on which one appears to have more latent capacity. -Rob > >> >> > >> > 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. >> > >> > --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. >> > >> > >> >> >> > > > -- > ---------------------------------------------------------------------------------------- > MzK > > "Women and cats will do as they please, > and men and dogs should relax and get used to the idea." > -- > Robert Heinlein
