[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Sidebar] - Interesting discussion on impact of "simple" HTTP requests

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 6 Jun 2012 02:16:27 -0400

On Tue, Jun 5, 2012 at 10:49 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>...
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=381620

Oh dear. I just looked at this bug report.

The basic problem is that they're talking to a "dumb" HTTP server. To
get anywhere, they need a custom server first. It sounds like that
hasn't even been started, let alone rolling out clients to start using
it. I'm not really comfortable dropping a comment here/there without
knowing the full scope of their system. I wouldn't want to give a bad
recommendation. Subversion was initially designed around WebDAV, and a
specific model designed on top of that. A decade of experience later,
we/CMike designed and built the HTTPv2 revamp. The short is: lots of
thought around the problem space.

For example, it looks like they need to do a bunch of format
negotiation. Use an Accepts: header, or build that into some kind of
manifest system? Today, they use a manifest. Maybe the client should
just have that, rather than fetching it? ... who knows.

There is certainly work that can be done against a dumb server, and it
looks like they're going through all the possibilities.

I saw in one of the bugs, they have 140 Mb total b/w, and about 80 of
that is available for downloads. So it isn't quite as gruesome as
Justin notes, but his point is valid: the primary issue is to shift
load off their servers. The ASF ran into that a decade ago, which is
why the mirrors are mandated.

Cheers,
-g

ps. and I'm actually a bit astounded that they haven't (yet) built a
custom server for their p2 system
Received on 2012-06-06 08:17:11 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.