On Fri, 10 Mar 2006 17:21:52 -0500, Daniel Veillard wrote:
okay got it. Please add a Changelog entry when you commit to the base :-) Will do.
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 :-)
One thing I should say is that I'm still contemplating changing the XML-RPC interface in Xend to make the libvirt a little easier..
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.
If I recall correctly, the S-Expression/HTTP errors are always 501 Internal Server error with no extended error message. Of course, I may be wrong.
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.
What Ewan and I had discussed at the Summit, was standardizing a set of exceptions for use as errors. I think this is a good idea. I would like to always keep the stack trace in the exceptions though as it makes debugging Xend considerably simpler. For something like libvirt, we could just look at the faultCode and use that to build an appropriate error message (based on current locale of course). Perhaps we could also offer an extended error message too that included the Xend faultMessage too.
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.
Oh, L4, good idea :-) I know just the person to talk to about that too... Regards, Anthony Liguori
Daniel
-- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/