Hi Alex, On Tue, Mar 29, 2016 at 09:44:39PM +0100, Alex Bligh wrote: > Eric, > > For all remaining existing commands, that is just more overhead on the > > wire. The existing non-structured replies do not send any data; they > > are 16 bytes each (only NBD_CMD_READ sends more than 16 bytes in one > > reply). But your proposal inflates that to a minimum of 20 bytes (if > > length is 0) or longer (if an error is set). I'm still strongly in > > favor of keeping the existing non-structured replies to commands that > > don't have to return data. > > I was saying that should be up to the server. If the server wants to > write something easily decodable (and easier to maintain) at the expense > of a few more bytes on the wire, then let it. If it wants to use > unstructured replies occasionally, that's fine.
In adding that flexibility, you're adding more code paths on the client (that need to be tested, etc), for (IMO) little benefit. I would instead prefer to specify per command whether the reply is going to be structured or not, and only have the read command be a special case were both are possible, for backwards compatibility only. That way, it can eventually be deprecated, too. -- < 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