[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Re: support for hvm guests

On Wed, May 10, 2006 at 03:20:15PM -0500, Anthony Liguori wrote:
> Karel Zak wrote:
> >On Wed, May 10, 2006 at 11:53:02AM -0500, Anthony Liguori wrote:
> >  
> >>>Don't think I want to waste anymore time with this bug since the http 
> >>>/ sexp interface is going away - which brings me to a question.  Why 
> >>>is libvirt still using this interface and not xmlrpc?  Perhaps my time 
> >>>would be better spent moving libvirt to this interface.  I would like 
> >>>to submit the hvm patch for libvirt but can't reliably test it at this 
> >>>point.
> >>>      
> >>wrt XML-RPC, I think I'm to blame for that.  I've not gotten around to 
> >>modifying the internals of libvirt to switch between 
> >>XML-RPC/S-Expression.  I'd suggest just reverting the xend_post to the 
> >>older code so you can keep making progress.
> >>    
> >
> > Note, I've commited some XMP-RPC tests and minor xml/xmlrpc code
> > changes to libvirt. It seems that Anthony's xmlrpc code works fine
> > against Python SimpleXMLRPCServer. For more details see CVS.
> >  
> As if there ever was any doubt ;-)

 No doubt about your code, but about my dirty hands that touch the
 code :-) 
 I'd like to add maximum unit tests. It's good way how we can 
 detect possible regressions in future changes.

> I ran most of that code through valgrind and tested it against the Xend 
> XML-RPC support.  The remaining work should be just plumbing the libvir 
> functions to use the XML-RPC functions.   The hardest part is probably 
> dealing with the S-Expressions since in XML-RPC they're going to be 
> returned as an Array instead of a string which means someone needs to 
> implement an XmlRpcArray -> struct sexpr conversion function.
> The other outstanding issue is that I used libxml2's nanoHttp interface 
> which won't work for a domain socket.  I think we may need to implement 
> our own HTTP code (or just borrow the code in the S-Expression interface 
> code).

 I think only one HTTP code in the library will be the best solution
 (= reuse the code in the S-Expression interface).

 Karel Zak  <kzak redhat com>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]