incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Feedback Requested: Proposed SourceForce Mirror of AOO 3.4
Date Mon, 26 Mar 2012 16:22:54 GMT
On Sun, Mar 25, 2012 at 9:20 AM, Mark Ramm <> wrote:

> >>   - would be the “recommended default download” on the
> website.
> >
> > What would that look like?  On what page do we make this branch?   In
> > most of our communications we will point the public to this URL:
> >
> >
> >
> > (That then redirects to
> >
> > The download link then provided to the user is matched to their
> > platform and language, based on their request headers.
> My thoughts would be that we split based on user preference at this
> page, by showing two links.  One for the download, and another
> for the apache mirror network based download.
This sounds good to me.

Any feedback from Apache Infra on this proposal?  Or anyone else from the
PPMC?  (Silence is consent)

> > Some subset (and we don't know what % since we're not running Google
> > Analytics here) don't want the default and click through to the full
> > matrix of downloads available:
> >
> >
> We can handle that however you want.   We can create a page
> matching that matrix, put links in the matrix along with normal
> mirror network links, or just leave it as is. We are open to whatever
> helps the project the most.
> > I'm assuming that we want to avoid duplicating effort maintaining the
> > logic for automatically matching users to the right download, as well
> > as avoid SF needing to tracking in detail a large matrix of downloads,
> > availability of new translations, etc.  You just want to mirror our
> > dist/incubator/ooo directory.
> already had user agent string + file name heuristics
> to figure out the right platform for the user and the "best match"
> download, which should work automatically.   We also allow projects to
> manually choose the "best" release for any given platform.  So, I
> think a simple link to
> (for example) would
> be enough.

Here is where it could get complex.  Not all languages are released at the
same time.  Some might come out when 3.4 is released initially.  Others
might then follow in later weeks, as the translations are completed.  Some
might not be available until 4.0.  So the calculation for what download to
recommend to a user is tricky, and would need to be responsive to the
changing status of translation availability.

One idea would be for us to agree on a single, canonical statement of these
matching rules/translation matrix, encoded in Javascript or XML or JSON or
something.  If we centrally manage that, then SF can periodically refresh
with the latest data, on a similar schedule to rsync'ing the actual

We can probably get started even with out this, but it might reduce the
coordination pain if we eventually move to a model like that.

> So it should be easy enough for that page to display both the
> link and one going to the Apache mirror network, and those can be
> displayed in whatever way makes the most sense for marketing the
> release and managing download traffic.

> Mirroring more files is not a problem for us at all as long as we can
> use rsync or some other automated mechanism to keep the files up to
> date as there are changes.
> Maintaining an alternative version/platform matrix page would take a
> little bit more work, but if it's helpful we could certianly create
> something that matches that experience on the side.
> > Ideally (and this is my opinion.  others may have better opinions), we
> > would check the user's request header, get the language and platform
> > from that, determine the recommended download, and pass that request
> > onto either of the mirror networks, along with the IP address for
> > locating the nearest mirror. The branch between Apache and SF mirrors
> > could be done randomly, based on a tune-able parameter.  if
> > rand()<0.25 doApache() else doSF() would send 25% of the download
> > requests to Apache, and the remaining 75% to SF.
> We can certainly do this as well.  Either approach is fine, but the
> approach outlined above has the advantage of requiring almost no
> integration work on either side -- so it would be my preference.
> That said, the approach you describe here could be implemented on the
> side in a day or two, so if it's your preference we're more
> than happy to accomodate that.
I think if we do branching at the top level page, 90% or more of users will
go for that first listed link. That is human nature. So if you are are
comfortable with that load then I have no objections. We could even balance
things at the Javascript level, with reordering those links to reach some
other distribution, e..g. place SF first 75% of the time, etc., depending
on what balance works best.

> > The nice thing about this approach is it allows each mirror network to
> > do their own geographic optimization, while allowing the OpenOffice
> > project to control how users are recommended a particular version of
> > AOO. It allows us to maintain the matrix of downloads in one place.
> > And it does not introduce any new mouse clicks for the user.
> I agree that we should try to maintain the current number of clicks.
> I also agree that we should give the OO project control of how the
> options are presented, and I like this idea.
> But the downside is that people might randomly get sometimes
> and apache mirrors the next, and have an inconsistent user experience.
>  And I also think users should have some control over what download
> experience they get.
> So, overall I think Joe's suggestion of a recommended download link
> that states that it's going to, and a second
> "alternate" link that goes the the Apache mirrors would probably
> provide a better user experience.
> > Is it technically feasible?
> Absolutely.  I think I speak for Roberto and the rest of the
> team when I say we are open to whatever solution works best for the
> AOO project, and are more than willing to be guided by the PPMC's
> opinion on this.
> --
> Mark Ramm
> Director of Engineering,
> SourceForge Developer Experience
> email:
> ====
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message