Re: [PATCH v3 12/35] serve: introduce git-serve

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 5, 2018, 21:36 UTC
Message-ID: <20180305213649.GF28067@aiede.svl.corp.google.com>
In-Reply-To: <20180305205254.GC5953@sigill.intra.peff.net>

Hi,

Jeff King wrote:

Show 8 quoted lines

> I agree that would be a lot more pleasant for adding protocol features.
> But I just worry that the stateful protocols get a lot less efficient.
> I'm having trouble coming up with an easy reproduction, but my
> recollection is that http has some nasty corner cases, because each
> round of "have" lines sent to the server has to summarize the previous
> conversation. So you can get a case where the client's requests keep
> getting bigger and bigger during the negotiation (and eventually getting
> large enough to cause problems).

That's not so much a corner case as just how negotiation works over http.

We want to do better (e.g. see [1]) but that's a bigger change than the initial protocol v2.

As Brandon explained it to me, we really do want to use stateless-rpc semantics by default, since that's just better for maintainability. Instead of having two protocols, one that is sane and one that struggles to hoist that into stateless-rpc, there would be one stateless baseline plus capabilities to make use of state.

For example, it would be nice to have a capability to remember negotiation state between rounds, to get around exactly the problem you're describing when using a stateful protocol. Stateless backends would just not advertise such a capability. But doing that without [1] still sort of feels like a cop-out. If we can get a reasonable baseline using ideas like [1] and then have a capability to keep server-side state as icing on the cake instead of having a negotiation process that only really makes sense when you have server-side state, then that would be even better.

> If anything, I wish we could push the http protocol in a more stateful
> direction with something like websockets. But I suspect that's an
> unrealistic dream, just because not everybody's http setup (proxies,
> etc) will be able to handle that.

Agreed. I think we have to continue to deal with stateless-rpc semantics, at least for the near future.

Jonathan

[1] https://public-inbox.org/git/20180227054638.GB65699@aiede.svl.corp.google.com/