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

[Ian Jackson]

Anthony Liguori writes ("Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce 
specification file"):
> 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.

I'm keen on RPC-like systems.  The main advantage is that you don't
have to invent and write a whole lot of marshalling and parsing code;
the RPC system will provide all that for you.  The more sophisticated
systems deal with message transport as well, so you don't need to mess
about with sockets either.

Parsers and formatters are one of the most tedious bits of code to
write and they are also critical for security, reliability and data
transparency.  It really doesn't make sense to roll your own for any
nontrivial problem.

If you pick the right RPC system you can get, entirely for free (well,
entirely piggybacking on other people's work) compact and efficiently
parseable binary wire formats.  Debugging trace output facilities,
which produce in nice human readable formats, are often provided as a
standard feature for no added effort.  Bindings for a wide variety of
programming languages can be easily found.  If you pick a bus- or
broker-based system (dbus, XDR, corba even) you get discovery and
rendezvous for free too.  Many systems have builtin facilities for
cross-version compatibility, of varying sophistication.

I would go further and say that we should use an RPC system with a
machine-readable IDL (Interface Description Language).  A formal IDL
provides an number of very significant advantages.  If you use an IDL,
the protocol is documented not primarily in a human-only-readable text
file, but primarily in the IDL, which means that the documentation
cannot get out of date.  Introspection and debugging features are
easier to provide because all of the programs have actual knowledge of
the message format and structure.  The wire formats can be much more
compact and efficient, because they do not need to tag every value
with its type and format - the receiving end knows what the format is
supposed to be and can get straight to unpicking it.

You can have an argument about which specific RPC mechanism to use,
but it's an embarrassment of riches compared to designing and writing
your own textual protocol, particularly if that protocol needs to be
quite complex and asynchronous.

I think dbus would be a good choice, but even XML-RPC (which, frankly,
is flabby, overcomplex, slow, hard to read, etc.), JSON (which doesn't
have an IDL that can even do checking), and ASN.1/DER/BER (which is a
complexity nightmare) would be an improvement over no automatic
parsing machinery.

> 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.

Yes.

Ian.