Shawn O. Pearce wrote:
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).
Not arguing that URL compatibility isn't a good thing, but there are
other ways to accomplish it, too. After detecting either a smart or
dumb server, we can use a redirect to point them to a different URL, as
appropriate.
Furthermore, in the case of round-robin sites like kernel.org, this is
actually *mandatory* in the case of a stateful server (we need a
redirect to a server-specific URL), and highly recommended in the case
of a stateless server (because of potential skew.)
-hpa
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
