Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

["Martin Ågren" <martin.agren@gmail.com>]

On 6 October 2017 at 22:27, Stefan Beller <sbeller@google.com> wrote:
>> I might be naive in thinking that protocol.version could be removed or
>> redefined at our discretion just because it's marked as "experimental".
>
> Well the redefinition might very well occur, when we now say "set to v1
> to test v1 and fallback to v0 otherwise", but long term we want a white
> or black list or some other protocol selection strategy encoded in this
> configuration (we would not want to introduce yet another config to work
> around the initial "failed experiment", would we?)
>
> And hence I would be careful how we define the meaning of
> protocol.version now.

Good points. If we want to go for a more general / future-proof wording
now, then we must already now implement the config-parsing as "does this
string contain the word '1'" instead of "is this string exactly '1'". If
we claim that "34 1 5" is a valid configuration, then the implementation
should accept it. (We'd probably also want to verify that there are only
integers and spaces in the string.)

> For example we could instead now claim "protocol.version is a whitelist
> of protocol versions, order is not specified. The only guarantee we're willing
> to give is that no protocol is used that is not on the list".

If we want to be able to list more than one version, we need to define
how to signal preference from the first day, IMHO. (I know you just gave
an example; I'm simply responding with what I think makes that example
non-ideal.)

The fact that v0 is requested by lack of data and all other protocols
(whether v1 or v34) have to be requested by presence of data, is a bit
unfortunate and it is bound to bleed through into the definitions, at
least until v0 is simply ripped out of git.git. Ok, this definition
suggests that "1 0" will be the preferred variant for checking basic
robustness, while "1" will be how to ensure you have a peer which knows
v1.

> All I was trying to say initially is that "we may try (one of) protocol.version,
> but fall back to whatever (currently v0)" is too broad. We'd need to redefine
> it shortly in the foreseeable future already.

Yes we would. I'll post a suggestion elsewhere in the thread.

Martin