On 03/02, Jeff King wrote: > On Fri, Feb 23, 2018 at 01:45:57PM -0800, Brandon Williams wrote: > > > I think this is the price of extending the protocol in a backward > > compatible way. If we don't want to be backwards compatible (allowing > > for graceful fallback to v1) then we could design this differently. > > Even so we're not completely out of luck just yet. > > > > Back when I introduced the GIT_PROTOCOL side-channel I was able to > > demonstrate that arbitrary data could be sent to the server and it would > > only respect the stuff it knows about. This means that we can do a > > follow up to v2 at some point to introduce an optimization where we can > > stuff a request into GIT_PROTOCOL and short-circuit the first round-trip > > if the server supports it. > > If that's our end-game, it does make me wonder if we'd be happier just > jumping to that at first. Before you started the v2 protocol work, I had > a rough patch series passing what I called "early capabilities". The > idea was to let the client speak a few optional capabilities before the > ref advertisement, and be ready for the server to ignore them > completely. That doesn't clean up all the warts with the v0 protocol, > but it handles the major one (allowing more efficient ref > advertisements).
I didn't really want to get to that just yet, simply because I want to try and keep the scope of this smaller while still being able to fix most of the issues we have with v0. > I dunno. There's a lot more going on here in v2 and I'm not sure I've > fully digested it. I tried to keep it similar enough to v0 such that it wouldn't be that big of a leap (small steps). For example negotiation is really done the same as it is in v0 during fetch (a next step would be to actually improve that). We can definitely talk about all this in more detail later this week too. > > > The great thing about this is that from the POV of the git-client, it > > doesn't care if its speaking using the git://, ssh://, file://, or > > http:// transport; it's all the same protocol. In my next re-roll I'll > > even drop the "# service" bit from the http server response and then the > > responses will truly be identical in all cases. > > This part has me a little confused still. The big difference between > http and the other protocols is that the other ones are full-duplex, and > http is a series of stateless request/response pairs. > > Are the other protocols becoming stateless request/response pairs, too? > Or will they be "the same protocol" only in the sense of using the same > transport? > > (There are a lot of reasons not to like the stateless pair thing; it has > some horrid corner cases during want/have negotiation). Junio made a comment on the Spec in the most recent version of the series about how I state that v2 is stateless and "MUST NOT" rely on state being stored on the server side. In reality I think this needs to be tweaked a bit because when you do have a full-duplex connection you may probably want to use that to reduce the amount of data that you send in some cases. In the current protocol http has a lot of additional stuff that's had to be done to it to get it to work with a protocol that was designed to be stateful first. What I want is for the protocol to be designed stateless first so that http functions essentially the same as ssh or file or git transports and we don't have to do any hackery to get it to work. This also makes it very simple to implement a new feature in the protocol because you only need to think about implementing it once instead of twice like you kind of have to do with v0. So in the most recent series everything is a chain of request/response pairs even in the non-http cases. In a previous version of the series I had each command being able to last any number of rounds and having a 'stateless' capability indicating if the command needed to be run stateless. I didn't think that was a good design because by default you are still designing the stateful thing first and the http (stateless) case can be an afterthought. So instead maybe we'll need commands which can benefit from state to have a 'stateful' feature that can be advertised when a full-duplex connection is possible. This still gives you the opportunity to not advertise that and have the same behavior over ssh as http. I actually remember hearing someone talk about how they would like to allow for ssh connections to their server and just have it be a proxy for http and this would enable that. -- Brandon Williams
