Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport

["Shawn O. Pearce" <spearce@spearce.org>]

"H. Peter Anvin" <hpa@zytor.com> wrote:
> Shawn O. Pearce wrote:
>>
>> Currently git-http-backend requests no caching for info/refs [...]
>
> Let's put it this way: we're not seeing a huge amount of load from git  
> protocol requests, and I'm going to assume "git+http" protocol to be  
> used only by sites behind braindamaged firewalls (everyone else would  
> use git protocol), so I'm not really all that worried about it.

Agreed.  There's another application I want git+http for, but that
may never materialize.  Or maybe it will someday.  I just have to
adopt a wait and see approach there.

> I'm not sure if "emulating a dumb server" is desirable at all; it seems  
> like it would at least in part defeat the purpose of minimizing the  
> transaction count and otherwise be as much of a "smart" server as the  
> medium permits.

I think it is a really good idea.  Then clients don't have to worry
about which HTTP URL is the "correct" one for them to be using.
End users will just magically get the smart git+http variant if
both sides support it and they need to use HTTP due to firewalls.
Clients will fall back onto the dumb protocol if the server doesn't
support smart clones.  Older clients (pre git+http) will still be
able to talk to a smart server, just slower.  This is nice for the
end user.  No thinking is required.

Never ask a human to do what a machine can do in less time.

I think its just 1 extra HTTP hit per fetch/push done against
a dumb server.  On a smart server that first hit will also give
us what we need to begin the conversation (the info/refs data).
On a dumb server its a wasted hit, but a dumb server is already
doing to suck.  One extra HTTP request against a dumb server is a
drop in the bucket.  Its also a pretty small request (an empty POST).

-- 
Shawn.