Re: [Nbd] [RFC PATCH] doc: In STRUCTURED_REPLY, make error types easy to recognize

2016-04-09 Thread Alex Bligh
On 9 Apr 2016, at 11:44, Wouter Verhelst wrote: > It's always easier to add new data at the end rather than in the middle. > With the former, you can just use a struct to read data off the wire, > and it won't change because someone changed the message. With the > latter, that

Re: [Nbd] [RFC PATCH] doc: In STRUCTURED_REPLY, make error types easy to recognize

2016-04-09 Thread Wouter Verhelst
On Sat, Apr 09, 2016 at 11:17:50AM +0100, Alex Bligh wrote: > > > > So, let's use two examples, of two different NBD_REPLY_TYPE_ERROR_OFFSET > > messages (one with string, the other without). As I originally wrote the > > RFC, they would be sent over the wire as: > > > > With my original RFC,

Re: [Nbd] [RFC PATCH] doc: In STRUCTURED_REPLY, make error types easy to recognize

2016-04-08 Thread Eric Blake
On 04/08/2016 11:17 AM, Alex Bligh wrote: > > On 8 Apr 2016, at 17:48, Eric Blake wrote: >> We may add future structured error replies; making it easy >> for older clients to properly treat such new reply types as >> an error gives us a bit more flexibility on introducing new

Re: [Nbd] [RFC PATCH] doc: In STRUCTURED_REPLY, make error types easy to recognize

2016-04-08 Thread Alex Bligh
On 8 Apr 2016, at 17:48, Eric Blake wrote: > We may add future structured error replies; making it easy > for older clients to properly treat such new reply types as > an error gives us a bit more flexibility on introducing new > errors to existing commands. Of course, good

[Nbd] [RFC PATCH] doc: In STRUCTURED_REPLY, make error types easy to recognize

2016-04-08 Thread Eric Blake
We may add future structured error replies; making it easy for older clients to properly treat such new reply types as an error gives us a bit more flexibility on introducing new errors to existing commands. Of course, good design practice says we should try hard to prevent the server from