From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1al0ps-0006dj-S0 for qemu-devel@nongnu.org; Tue, 29 Mar 2016 17:06:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1al0po-0002jx-Ts for qemu-devel@nongnu.org; Tue, 29 Mar 2016 17:06:00 -0400 Received: from barbershop.grep.be ([89.106.240.122]:43057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1al0po-0002jm-OA for qemu-devel@nongnu.org; Tue, 29 Mar 2016 17:05:56 -0400 Date: Tue, 29 Mar 2016 23:05:45 +0200 From: Wouter Verhelst Message-ID: <20160329210545.GB19767@grep.be> References: <1459173555-4890-1-git-send-email-eblake@redhat.com> <1459223796-28474-2-git-send-email-eblake@redhat.com> <20160329175319.GA8628@grep.be> <56FAC823.8070206@redhat.com> <20160329185157.GC12469@grep.be> <56FADEFA.8070207@redhat.com> <7E85EC50-7289-43CA-8DCC-D933B4B28A22@alex.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E85EC50-7289-43CA-8DCC-D933B4B28A22@alex.org.uk> Subject: Re: [Qemu-devel] [Nbd] [PATCH 3/1] doc: Propose Structured Replies extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" 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