[Libvir] XML-RPC support for libvirt

[Anthony Liguori]

Howdy,

I'm about to checkin some XML-RPC code into CVS.  The code I'm checking 
in won't compile by default (for now) as there's still a little work to 
do but I wanted to get something into the tree.  Here are the tasks left:

1) Convert from dict to s-expressions to handle config returns.  Right 
now, the Xend XML-RPC code returns S-Expressions in the form of a 
tuple.  We just need a little code to convert from these tuples to 
struct sexpr's.

2) Integrate my unit tests.  I've got a number of unit tests that stress 
the various bits of parsing code.  I'd like to add a make check that 
runs these unit tests and a make fullcheck that runs these unit tests 
under valgrind.

3) Support XML-RPC over a domain socket.  Right now I'm using nanohttp 
which doesn't appear to allow different transports.  There is some HTTP 
PUT code already in the tree so I could use that if there isn't a more 
clever solution.

4) Plumb the xend backend functions to XML-RPC.  This is really straight 
forward.  It's just a matter of converting:

int
xend_pause(virConnectPtr xend, const char *name)
{
    return xend_op(xend, name, "op", "pause", NULL);
}

To:

int
xend_pause(virConnectPtr xend, const char *name)
{
    if (xend->xmlrpc)
        return xmlRpcCall(xend->xmlrpc, "xend.domain.pause", "", "s", name)
    else
        return xend_op(xend, name, "op", "pause", NULL);
}

Of course, using the xml-rpc code, we now have access to rich fault 
information.  Xend never actually returns errors for things and instead 
throws exceptions.  For the S-Expression/HTTP protocol, you just get a 
501 and have to return a meaningless error.  With XML-RPC, those 
exceptions are actually serialized and sent over the wire.  We may want 
to explore how we can make that information available to the user.

My current understanding, btw, is that the basic XML-RPC support for 
Xend is going into the tree sometime this week (Ewan is looking at the 
code now) and will be a part of the 3.0.2 release.  This means that for 
the 3.0.3 cycle, we'll be defining a standard API.  This process will be 
starting soon (within the next couple of weeks hopefully).

Regards,

Anthony Liguori