From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57572 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ODv1b-0006V8-TQ for qemu-devel@nongnu.org; Mon, 17 May 2010 03:46:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ODv1a-0000FC-3q for qemu-devel@nongnu.org; Mon, 17 May 2010 03:46:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17021) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ODv1Z-0000Ex-Qa for qemu-devel@nongnu.org; Mon, 17 May 2010 03:46:06 -0400 Message-ID: <4BF0F437.6040302@redhat.com> Date: Mon, 17 May 2010 10:45:59 +0300 From: Avi Kivity 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> In-Reply-To: <4BF0F2FD.90408@siemens.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: Jan Kiszka Cc: Anthony Liguori , Juan Quintela , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino 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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.