qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Nbd] [PATCH 3/1] doc: Propose Structured Replies exten


From: Wouter Verhelst
Subject: Re: [Qemu-devel] [Nbd] [PATCH 3/1] doc: Propose Structured Replies extension
Date: Tue, 29 Mar 2016 23:05:45 +0200
User-agent: Mutt/1.5.24 (2015-08-30)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]