On 04/20/2012 09:24 AM, Rob Weir wrote:
On Fri, Apr 20, 2012 at 6:06 PM, Kay Schenk<[email protected]> wrote:
On Thu, Apr 19, 2012 at 7:36 PM, drew<[email protected]> 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,
1) and 2) great plan and pretty much what I was thinking as well! Good!
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.
OK, but right now we're still plagued with the "no connection"
business...we could just leave things like that until light dawns on
this I guess.
Anyway, I WILL put something together early next week -- Mon, Tues -- on
this. I'm busy over the next few days.
-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
--
------------------------------------------------------------------------
MzK
"Women and cats will do as they please,
and men and dogs should relax and get used to the idea."
-- Robert Heinlein
