Re: [PATCH v2 5/8] Documentation: add Packfile URIs design doc

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 24, 2019, 03:01 UTC
Message-ID: <xmqqftq82jjd.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190423053130.GA13162@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

> I.e., I think the conversation ought to be more like:
>
>   Server: I support packfile-uris X, Y, Z.
>
>   Client: Great. I'll use URIs X and Z.
>
>   Server: OK, here's your pack, minus any objects I know are in X and Z.
>           I'll send you the objects from Y as normal.

I agree with the overall direction, but I am afraid that the server advertisement may have to become a lot more complex.

For example, are you assuming in the above example that X, Y and Z are not overlapping?

Or perhaps X is the whole repository that is quick to access only from European clients, while Y and Z combined have the same set of objects that are meant for our Asian friends. IOW, the server may expect that the client would say one of three "there is nothing I can use then", "I am happy with X and won't use Y and Z" or "I'll use Y and Z then, without X", and no other combinations like "I'll use X and Z" may make sense.

Show 6 quoted lines

> And then the client is free to pick and choose. The initial server uri
> list can come in the capabilities list, or it can be a separate request
> once the client sees the server supports packfile-uris and wants to ask
> about them. We may need some way for the server to group the uris so
> that the client knows which ones are alternates of each other (and which
> ones are needed to make a complete set).

I guess what I am saying is that it is not so clear how we can present the server offered URIs to the client in such a way that the client (either mechanically, or consulting the human) can make a useful choice,