On Fri, Mar 10, 2006 at 10:57:59AM -0600, Anthony Liguori wrote:
Howdy,
Evening ;-)
I'm about to checkin some XML-RPC code into CVS. The code
I'm checking
okay got it. Please add a Changelog entry when you commit to the base :-)
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);
}
Okay the steps needed look fairly clear, thanks :-)
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.
the new error code tries at least to extract the error message when
an HTTP POST or GEt fails with an error code, but the XML-RPC should
give a far more reliable framework for error handling.
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.
I would say as a buffer at least that's no problem. But exposing
the structure of the error stack on the server may be a bit too much.
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
That's waht I was told too :-)
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).
Excellent ! Good good !
Hopefully we will be able to confront that with what is present in other
engines like l4 and QEmu and make sure at least for the 'common' APIs
the semantic is similar.
Daniel
--
Daniel Veillard | Red Hat
http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/