qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Wed, 24 Jun 2009 16:09:38 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2

On 06/24/2009 03:46 PM, Anthony Liguori wrote:
There are two questions to resolve. The first is whether we should continue with the current direction (line-based protocol) or whether we should switch to an RPC. The second question is which RPC we should use.

I'm not at all convinced that we should switch to an RPC mechanism in the first place. Perhaps someone could summarize the advantages of doing this because right now, I don't see many.

Less effort for us.

Less effort for clients.

Less documentation effort.

Less likelihood of design and implementation holes (cf. UTF-8, quoting).

Richer data types (arrays, structures, nesting).

With respect to RPC choice, if we did go that route, I'd be very concerned about using jsonrpc verses a more well established rpc. I would honestly prefer xml-rpc over jsonrpc.

I agree xml-rpc is a more rational choice than jsonrpc, but I cannot find it in my heart to say something nice about xml. Additionally, XML parsers are pretty heavy.

One reason to choose an RPC is based on the adoption of it. You want to use something that has a vibrant community with well established client libraries to make writing clients as easy as possible. Without an active jsonrpc C library, it's hard to argue that jsonrpc has that. xml-rpc certainly does.

jsonrpc really is a trivial addition over json, and json is pretty widespread. I think I saw a Python jsonrpc implementation.

The important thing however is to reuse, it doesn't really matter what we reuse really as long as it's good enough.

--
error compiling committee.c: too many arguments to function





reply via email to

[Prev in Thread] Current Thread [Next in Thread]