On Tue, Apr 19, 2016 at 01:28:41PM +0100, Alex Bligh wrote:
> 
> On 19 Apr 2016, at 13:04, Eric Blake <[email protected]> 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

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general

Reply via email to