On Fri, Mar 10, 2006 at 04:35:11PM -0600, Anthony Liguori wrote: > On Fri, 10 Mar 2006 17:21:52 -0500, Daniel Veillard wrote: > 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.. Well don't think specifically in libvirt terms, but what canonical interfaces are the most likely to be suitable for apps :-) > >> 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. There is an error message in the content of the GET/POST returned, I extract it now, running "make tests" show: /u/veillard/libvirt/python/tests ## running Python regression tests libvir: Xen Daemon error : GET operation failed: No such domain test That is a message output by the library. The python shutdown the 'test' domain and loop trying to get state every second until a failure. The failure ends up being reported (i.e. success :-) "GET operation failed" comes from libvirt, while "No such domain test" is the error message extrated from the failed HTTP request, I think it work alike for POST ones. Still this is limited and XML-RPC should be better in this respect :-) > >> 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. Sure sounds a good idea > 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. appropriate error message yes. locale hum I'm not fond of it. libvirt is too low in the stack, I would not expect the 'message' to be directly useful to an user, but one must give as much informations as possible to the software on top to be able to analyze and present a correct, in-context error if needed. > > 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... Well Ronald Aigner who joined the list 2 days ago from Desden Univ certainly seems to come from the l4 group there, but sure get more people on this list, so we have less risk to fail our API designs ;-) 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/