From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38493 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ODvPu-0004RI-GJ for qemu-devel@nongnu.org; Mon, 17 May 2010 04:11:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ODvPn-0004J5-SN for qemu-devel@nongnu.org; Mon, 17 May 2010 04:11:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48160) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ODvPn-0004In-Gy for qemu-devel@nongnu.org; Mon, 17 May 2010 04:11:07 -0400 Message-ID: <4BF0FA13.10808@redhat.com> Date: Mon, 17 May 2010 11:10: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> <4BF0F437.6040302@redhat.com> <4BF0F6D3.8020803@siemens.com> In-Reply-To: <4BF0F6D3.8020803@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:57 AM, Jan Kiszka wrote: > 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. >> > There is a schema describing the fields (name, size, number of > elements), Surely the schema has to describe the type as well? If it does, you can use the schema to generate a classes at compile time. > but their types (int, buffer, sub-field, array of X) are > derived from the JSON objects (ie. the JSON parser does this job). > The names of fields are also type information. >>> 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. >> > What clients do you have in mind? > > Any client that doesn't allow object types to be created dynamically; C, C++, Java, and the like could all benefit from a schema and wouldn't be able to do much with __class__ unless all classes were predefined. Python, JavaScript, and the like wouldn't care. Another way of looking at it: if the client sees { __class__: foo, f1: 10, f2: 9 }, it cannot derive any information from __class__ unless it was aware of foo beforehand. If that's the case, let's make it part of the schema so it is available at compile time instead of runtime. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.