|Subject:||Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file|
|Date:||Thu, 25 Jun 2009 14:54:40 -0500|
|User-agent:||Thunderbird 220.127.116.11 (X11/20090320)|
Avi Kivity wrote:
Adopting an RPC should be easier than adopting QMP, since all you have to do is compile the IDL. Again I point to the incremental cost of adding a command.
Having written clients for XML-RPC, SExpr/HTTP, and the QEMU monitor, in both C and in Python, along with having spent way too much time with various IDL compilers, I really don't agree with you here.
It is relatively easy to parse a line based protocol. Certainly easier than most poorly designed RPCs. For RPCs that are not self-described, you need an IDL compiler to make any sense out of the packets. IDL compilers are a huge problem because you need to build the compiler and run it on the same platform unless you choose from the handful of common compilers. Those compilers/RPCs tend to produce absolutely terrible C code so you need to do all sorts of tricks to avoid excessive warnings.
For self-describing RPCs (like XML-RPC), you can avoid IDL which is good. You still end up with pretty funky C code though and the type system almost always comes back to haunt you.
This is exactly what happened with Xend's transition from SExpr/HTTP (custom RPC) -> XML-RPC -> XenAPI. libvirt still uses SExpr/HTTP because the cost of switching to the new way of doing things didn't warrant the return on investment.I think this points to libvirt doing something wrong. I suspect it's the implementation language.s/libvirt/any other management tool that works today/gAnything written in a high level language (say, Python) will be trivial to port to an RPC. RPC clients in Python can be typed in with one finger in a couple of minutes.
Reality is less rosy. Take a look at Xend's XML-RPC server/client. Python doesn't provide anything but the most dumb transports. Implementing custom transports requires poking internal bits of the class library. It gets ugly really quickly.
Also, typing really hurts with dynamic languages because the type semantics never match up well which causes unexpected failures. A classic example with XML-RPC is None. There is no standard way to transport None in XML-RPC although there are common extensions to support it. Of course, not all clients support it and there isn't really a standard way to negotiate it. It's really a mess.
At this point, we have a close-to-mergable set of patches that provide real value. I don't see a reason not to merge them once they've been resubmitted.
I don't believe an RPC is going to be a dramatic simplification. It could be if there were a high quality RPC out there that had well maintained client/server libraries. I don't believe such a thing exists though. If you want to keep arguing this, let's focus on actual RPC implementations. I think we've agreed that JSON-RPC isn't going to work because of the lack of client/server library availability. XML-RPC falls into the same boat for C as far as I'm concerned. If there are any other ones you want to consider, let's look at them so that we can make progress in this discussion.
Regards, Anthony Liguori
|[Prev in Thread]||Current Thread||[Next in Thread]|