Re: Proposal for "fetch-any-blob Git protocol" and server design

From: Jonathan Tan <jonathantanmy@google.com>
Date: Mar 16, 2017, 22:48 UTC
Message-ID: <3c89fee5-2226-6760-f2fd-222432230612@google.com>
In-Reply-To: <xmqq7f3oc45v.fsf@gitster.mtv.corp.google.com>

On 03/16/2017 02:17 PM, Junio C Hamano wrote:

Show 10 quoted lines

> Yeah, the example was solely to see how the system was to be
> extended, as one of the selling point of the proposal was:
>
>     > === Endpoint support for forward compatibility
>     >
>     > This "server" endpoint requires that the first line be understood, but
>     > will ignore any other lines starting with words that it does not
>     > understand. This allows new "commands" to be added (distinguished by
>     > their first lines) and existing commands to be "upgraded" with
>     > backwards compatibility.

<snip>

>
> And the lack of "capability negotiation" is substituted by "assume
> the better server, fallback to lower common denominator by detecting
> errors"?

Yes. I probably should have mentioned that this "forward compatibility" is limited - it does not include any potential new feature intending to reduce the size of the request. I was thinking more of this being able to be extended to, for example, add "hint" lines that certain blobs come from certain commits, or add "have" lines to present blobs that might be good delta bases (and even if the server doesn't understand these lines, its output is still correct).