From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60914 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OE018-0001KQ-3I for qemu-devel@nongnu.org; Mon, 17 May 2010 09:06:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OE016-0006ER-2I for qemu-devel@nongnu.org; Mon, 17 May 2010 09:05:57 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:42623) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OE015-0006EK-VE for qemu-devel@nongnu.org; Mon, 17 May 2010 09:05:56 -0400 Received: by gyd5 with SMTP id 5so2139421gyd.4 for ; Mon, 17 May 2010 06:05:55 -0700 (PDT) Message-ID: <4BF13F2F.7030205@codemonkey.ws> Date: Mon, 17 May 2010 08:05:51 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <6e14cbfe3764b46d9bd6d2db61d41fd9c85dd54e.1273843151.git.jan.kiszka@siemens.com> <4BED9358.1000106@codemonkey.ws> <20100516173809.GA29814@shareable.org> <4BF0E6CD.7090909@redhat.com> <4BF0F2FD.90408@siemens.com> <4BF0F437.6040302@redhat.com> In-Reply-To: <4BF0F437.6040302@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Juan Quintela , Jan Kiszka , qemu-devel@nongnu.org, Luiz Capitulino , Markus Armbruster On 05/17/2010 02:45 AM, Avi Kivity wrote: > On 05/17/2010 10:40 AM, Jan Kiszka wrote: >> >>> The alternative is to have a schema. Sun RPC/XDR doesn't carry any >>> type >>> information (you can't even distinguish between a number and text) >>> yet C >>> clients have to problem extracting typed information from it. >>> >>> Having __class__ everywhere means we're carrying the schema in every >>> message instead of just once. >> The device_show command is already an example where you don't have a >> predefined schema. It is derived from the data stream the encodes the >> vmstate fields. So far we have no collision between base64-encoded >> buffers and real strings, but this may actually change when we start >> annotating the fields with symbolic constants. > > What is the receiver to do with it? > > If it doesn't know the schema (and there is no schema), then all it > can do is display the key/values. If it does know the schema, then > __class__ is unnecessary. > > My worry is that __class__ will make the protocol more ad-hoc. > >> I really don't see the problem with __class__. Being a text protocol, >> JSON is already fairly verbose. > > The problem is not the verbosity, it's that information is carried too > late. Many clients want to know this information at compile time or > initialization time, and we are providing it at object instantiating > time. Whether a protocol is self-describing is orthogonal to whether it's well defined (ala a schema). A self-describing protocol is very convenient for dynamic languages like Python. We should also provide a formal schema though for languages that require IDL to generate bindings (like C). Regards, Anthony Liguori