[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] Xend XML-RPC Refactoring
On Tue, Jan 31, 2006 at 03:25:58PM -0600, Anthony Liguori wrote: > Hi, > > I wanted to give the list a heads up about something a number of us > discussed at the recent XenSummit. > > We would like to simplify Xend by utilizing more of the standard Python > library and relying on less of our own code. The most obvious thing > here is the current S-Expression/HTTP RPC interface. We would like to > replace this with XML-RPC using Python's builtin support (xmlrpclib and > SimpleXMLRPCServer). > > I've got some initial code and more details on the wiki > (http://wiki.xensource.com/xenwiki/Xend/XML-RPC). Early estimates are > that this would reduce the code in Xend by about 33% (5k slocs). We > would also like to standardize this XML-RPC interface so that > third-parties write apps to this interface without worrying about > massive breakage. > > Thoughts? Going to XML is fine by me, the only drawback I can think of is in term of versatility and larger (but stabler) dependancies. To be a bit more explicit on the first point if you pass an S-exp it's some kind of free form function call, the caller may pass more arguments or a slightly different set without breaking fundamentally the interface, the callee may still be able to extract the set of informations he needs to prepare the call, the same applies in terms of result set too. Think about the call gathering informations about a running domain, version 4.0 of xen may return a superset of what 3.0 returns without harming 3.0 based clients, so there is clearly some added flexibility compared to a normal RPC operation. On the other hand being able to feeze a clear RPC based API would be a good sign, that we know exactly how we intend to keep the APIs in the future. And when it comes to the final API design, the current ones are IMHO too name oriented when it comes to naming domains, I would really prefer the final XML-RPC ones to be more id and uuid oriented, as I think they are more safe (especially when one considers the rename capacity, this may lead to numerous races between the time one client does the uuid -> name resolution and the next name based next call). thanks for starting this ! 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/ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |