From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53712 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBTli-0008Uk-2W for qemu-devel@nongnu.org; Mon, 10 May 2010 10:16:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBTku-00034T-9C for qemu-devel@nongnu.org; Mon, 10 May 2010 10:15:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40391) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBTkt-000342-UM for qemu-devel@nongnu.org; Mon, 10 May 2010 10:14:48 -0400 Message-ID: <4BE814D1.3050209@redhat.com> Date: Mon, 10 May 2010 17:14:41 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Registering buffers with a qdict References: <4BE3FD3F.4070606@siemens.com> <20100507100758.1050a374@redhat.com> <4BE421D9.30502@siemens.com> <20100507135902.2753bb4a@redhat.com> <4BE7E723.3000002@siemens.com> <4BE80A04.9090705@redhat.com> <4BE80D8C.4050609@siemens.com> In-Reply-To: <4BE80D8C.4050609@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , Luiz Capitulino On 05/10/2010 04:43 PM, Jan Kiszka wrote: > Avi Kivity wrote: > >> On 05/10/2010 01:59 PM, Jan Kiszka wrote: >> >>> From a quick glance at the JSON spec, there is no room for a new type. I >>> think we have to overload an existing one and convert that into a >>> QBuffer (typically, we know the actual semantic). Hex string encoding is >>> most compact, so I went this road. >>> >> Base64 is even more compact. >> > For sure, still room for improvements. There is just no encode() service > in current qemu, so I went the lazy way so far. :) > Well, if we expose these encoded buffers via QMP, we can't unlazy the implementation. It becomes an ABI, so we better think (and document) this through. >>> But I'm open to change it into a true >>> type if JSON actually allows it (or we are fine with breaking it). >>> >>> >> That ruins any possibility of using a standard json encoder/decoder on >> the other end. >> >> > That was my concern as well. Such decoders would not able to tell > strings apart from buffers as that can only be derived from the context. > Still, they could visualize the result and/or forward it to some libqmp > for proper interpretation. > That's fine; the documentation for a command that accepts or returns buffers would mention that the value is a hex (or base64) encoded string. -- error compiling committee.c: too many arguments to function