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@xxxxxxxxxx |
> libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/
> | Rpmfind RPM search engine http://rpmfind.net/