Re: [Nbd] [PATCH] doc: Specific error if NBD_OPT_GO refused without NBD_OPT_BLOCK_SIZE

[Wouter Verhelst <w@...112...>]

On Tue, Apr 19, 2016 at 01:28:41PM +0100, Alex Bligh wrote:
> 
> On 19 Apr 2016, at 13:04, Eric Blake <eblake@...696...> wrote:
> 
> >>> 
> >>> Question: Should we rearrange the various errors, so that
> >>> NBD_REP_ERR_UNKNOWN and NBD_REP_ERR_BLOCK_SIZE_REQD are
> >>> adjacent (since they are, for now, in the same extension
> >>> branch), by hoising NBD_REP_ERR_SHUTDOWN to 2^32 + 6?  We
> >>> don't yet have any released versions that use
> >>> NBD_REP_ERR_SHUTDOWN, although it was added as normative text
> >>> without going through the usual extension work.
> > 
> > Likewise for putting NBD_OPT_BLOCK_SIZE adjacent to NBD_OPT_GO if we
> > keep block sizes as part of the INFO extension rather than its own.
> 
> So I think we can be pretty free and easy with the stuff in
> extensions. But for things in master, I think we should try not to
> change them once they are in. I know in this instance it's a tiny
> thing, and it's only been a matter of days, but it would also have
> only a tiny gain. Therefore I think not.

Right.

> Incidentally I don't think normative text necessarily needs to go
> through an 'extension' phase. For instance, if Wouter agrees with us
> on synchronizing the options haggling phase, we can't really have a
> 'synchronized option haggling' extension (or whatever the opposite of
> an extension is).

Not really, no :-)

> I see extensions as a proving ground for protocol, um, extensions that
> though we all like the idea, we know are going to have lots of
> wrinkles to smooth out during implementation.

That's the idea, yeah.

> I don't think adding one error code would fall into that category (not
> that I'm implying you thought it did).

Wellll, I think it does (in this case). I'm not sure I like the
backwards compatibility repercussions of allowing a server to say
NBD_REP_ERR_BLOCK_REQD (or whatever the name was), and so they may need
to be fleshed out a bit more.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12