From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47657 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ODw6q-0001nG-W8 for qemu-devel@nongnu.org; Mon, 17 May 2010 04:55:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ODw6p-0002lw-1N for qemu-devel@nongnu.org; Mon, 17 May 2010 04:55:36 -0400 Received: from david.siemens.de ([192.35.17.14]:21680) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ODw6o-0002lc-Gm for qemu-devel@nongnu.org; Mon, 17 May 2010 04:55:34 -0400 Message-ID: <4BF10481.7030900@siemens.com> Date: Mon, 17 May 2010 10:55:29 +0200 From: Jan Kiszka 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> <4BF0FA13.10808@redhat.com> In-Reply-To: <4BF0FA13.10808@redhat.com> Content-Type: text/plain; charset=UTF-8 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 , "qemu-devel@nongnu.org" , Markus Armbruster , Luiz Capitulino Avi Kivity wrote: > 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. Not in the case of device_show. The clients have no idea of the vmstate structures before they were transfered. Granted, that will likely remain a special case in the QMP command set. > >>>> 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. > Maybe a misunderstanding on my side: I'm not arguing against predefining what __class__ values exists and how dicts that carry such keys are encoded. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux