Am 08/02/2011 12:49 AM, schrieb Rob Weir:
On Mon, Aug 1, 2011 at 6:42 PM, Marcus (OOo)<marcus.m...@wtnet.de>  wrote:
Am 08/02/2011 12:15 AM, schrieb Ross Gardler:

On 1 August 2011 22:51, Marcus (OOo)<marcus.m...@wtnet.de>    wrote:

Am 08/01/2011 09:25 PM, schrieb Ross Gardler:

On 1 August 2011 18:20, Marcus (OOo)<marcus.m...@wtnet.de>      wrote:

AFAIK the current projects at Apache doesn't have high download numbers
compared with OOo. So, a download request can point directly to a
mirror
or
a mirror list is shown and the users have to choose themselves from
where
to
get the software best.

I wouldn't make any assumptions about the current mirror
infrastructure. What you write above does not reflect how things work
here. The ASF is a pretty large collection of projects with some very
large numbers behind it.

I've looked at this both pages:

http://www.apache.org/dyn/closer.cgi
http://httpd.apache.org/download.cgi

When comparing it with the one from the current OOo project you should be
able to see big differences:

- too many links
- too much data on one page
- too much information to read to get an overview
- too less clear structure

So what do you want? A single download link that automatically selects
the most appropriate mirror for the user?

Yes. Everything else is not end-user compatible and needs to much effort to
explain.

That's easily done. I think you might be confusing the way that some
projects choose to implement the download with how OO.o would be
expected to implement the download.

The ASF does not care what your download page looks like as long as
you use the CGI scripts to ensure that an appropriate mirror site is
used.

Hm, let's see how independent the download thing really will be. ;-)


Well, I think it is obvious that it is better to have a a single
mirror system with the ability to customize the UI for each project
than to have each project seek out a different mirroring network.

Of course, I don't want to force the OOo mirror system now into the Apache project. It's how to make the best use of it.

> In
other words, let's try to solve this with a JavaScript "hammer" if we
can, and save the VM "hammer" for if we really need it.

AFAIK we have tried it with JS but have decided to use Bouncer (from OSUOSL) and due to problems migrated then to MirrorBrain. MirrorBrain isn't and doesn't need a VM "hammer". Currently it's running on a SuSE system with 512 MB RAM.

Marcus

Reply via email to