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: Sun, 28 Jun 2009 20:34:44 +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/28/2009 08:23 PM, Anthony Liguori wrote:
It's important to allow clients to use json emitters so they can construct a dict and throw it at qemu, similarly to parse qemu results.

arg_list: value arg_list?

command: symbol arg_list? '\n'

Better to use a dictionary for the argument list (more self-documenting, easier expansion).

Verses a list? I'm not sure a dict fits the current QEMU model very well. How would you propose fitting it into the current monitor infrastructure?

First, I would like to consider the protocol mostly from the point of view of clients, not qemu, and certainly not current qemu code. There is only one qemu, but many clients. Code problems can be solved tomorrow, but interface problems remain forever.

Second, I think it fits quite nicely. Positional arguments are nasty when you have many of them, especially when some are optional. And we already support dictionaries: -drive file=blah,cache=none. We make a dictionary interface, and have both the command line parser and the monitor json thing implement it.

(note: it would be nice to have this interface detect unused arguments so we can flag typos in keywords).

Similarly, return a value that contains message type, id, and return value.

I think command outputs are basically return values. What's nice about the current QMP proposal is that we're basically returning tuples.

Yes, I meant { 'type': 'respose', 'id': 'foo', 'return': value }. 'type' is the new =, and 'id' is the tag. If multiple return values are needed, value can be a list or dictionary.

I think it's fine to drop jsonrpc as the standard (but retain its features) and just adopt json for encoding.

Yeah, I think if we focus on defining a grammar and semantics, if it happens to look like JSON, I don't really care. I just don't want to adopt the baggage of json and particularly json-rpc.

If 'looks like' == 'compatible with', I agree.

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





reply via email to

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