[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Sun, 28 Jun 2009 19:42:55 -0500
User-agent: Thunderbird (X11/20090320)

Avi Kivity wrote:
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.

I'm trying to consider both. We need something that we can get into a robust state in 6 months. I don't want to undertake a massive effort that will require major changes because history shows that we'll end up with something that doesn't really do the job.

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.

It a fair bit of complexity but I don't think it's too problematic. The current monitor abstraction doesn't have a mechanism to define names of arguments but I think it could be added relatively easily although it wouldn't be so elegant (another parameter with comma deliminated names would do the trick).

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 really don't like the syntax you proposed but that's an aesthetic problem. This is an interface consumed by non humans so I don't think it's worth arguing about something that is just as easily parsed by a computer even if it's hideously ugly :-)

So I'll defer to whatever Luiz (or whoever sends patches) decides to do as long as it meets the same requirements.

The main thing missing from the first patchset that this thread has revealed is a formal grammar for the data. This is an important requirement to ensure that it's reasonably parse-able by both ends.

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.

You lost me here. JSON interoperability cannot be a requirement. Otherwise, we're going to get stuck dealing with all the warts of JSON. I don't want people to assume they can just use a JSON parser.

You seem to have conflicting requirements. You want JSON compatibility but then you want C-style floats which JSON doesn't support.

I don't mind if this ends up looking like JSON, but I don't want to have to enforce that it's remains JSON compatible in the long term. We should have our own grammar that we can version and that people can use as the basis of a client.

If being pure JSON is important to someone (and I don't think it will be), then someone can write a JSON proxy. You don't need any RPC knowledge to do that so it can be relatively future-proof.


Anthony Liguori

reply via email to

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