a last comment on xml-rpc

a last comment on xml-rpc

[Ronald G Minnich]

we get this kind of note all the time, and just got another one.

Chessbrain II, which used to use XML-RPC, has moved to Matt's 
s-expression library. For more on chessbrain:

"It is being used in two projects, msgCourier (an open source messaging 
server) and on the ChessBrain project.  ChessBrain is a distributed 
computing project (similar to SETI@home) that plays the game of chess 
using thousands of computers.  ChessBrain was awarded a 2005 Guinness 
World Record involving distributed computation (see 
http://www.chessbrain.net and http://www.msgcourier.com).  The new 
ChessBrain II (which has been in development for two years now) will 
utilize msgCourier during its next world record attempt in Copenhagen. 
The underlying communication protocol will use s-expr and Matt's sfsexp."


I think Xen made the right decision, in the beginning, to use s-exprs. 
We have heard from any number of places that learned the hard way that 
XML is a really poor foundation for RPC.

I hope you will reconsider going to XML-RPC. I don't think the existence 
of python support is sufficient. The whole point of RPC, in fact, is to 
let any client talk to any server, without regard to language or 
environment. We know in practice that trivial C programs can use 
s-expression based RPC; we've seen how awful the XML parsers in C can 
be; do you really want to lock C out of this picture?

thanks

ron

Re: a last comment on xml-rpc

[Anthony Liguori]

Ronald G Minnich wrote:
> I think Xen made the right decision, in the beginning, to use s-exprs. 
> We have heard from any number of places that learned the hard way that 
> XML is a really poor foundation for RPC.
>
> I hope you will reconsider going to XML-RPC. I don't think the 
> existence of python support is sufficient. The whole point of RPC, in 
> fact, is to let any client talk to any server, without regard to 
> language or environment. We know in practice that trivial C programs 
> can use s-expression based RPC; we've seen how awful the XML parsers 
> in C can be; do you really want to lock C out of this picture?
I don't think that's fair at all.  I've written the C code to interface 
with Xend using S-Expression/HTTP and it's painful (see libvirt).

I've also written an XML-RPC interface to Xend in C using libxml2.  It 
very little code and just works.  Granted, parsing XML is more painful 
that parsing S-Expressions but there are so many libraries for so many 
languages that XML parsing is really a nop.

I don't see any point in rolling out our own RPC mechanism when a 
standard one exists that is well supported in most languages.  There is 
also a C library that provides support for XML-RPC (libxmlrpc_c) so 
interfacing with Xend using C would require no additional code on the 
client side.  All the major high level languages I know of have XML-RPC 
support as part of the standard library.

We're talking about a pretty significant reduction in code in Xend too 
by moving to XML-RPC.  If Python supported a different RPC mechanism I 
would support moving to that simply to reduce the complexity of Xend.

Regards,

Anthony Liguori
> thanks
>
> ron
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: a last comment on xml-rpc

[Ronald G Minnich]

Anthony, you are obviously closer to this than I am, so I will yield to 
you on this one :-)

thanks

ron

Re: a last comment on xml-rpc

[Matt Sottile]

> I don't think that's fair at all.  I've written the C code to  
> interface with Xend using S-Expression/HTTP and it's painful (see  
> libvirt).

S-expressions transported over a hypertext transfer protocol?  Python  
inside a virtualization daemon?  RPC for interprocess  
communications?  There is definitely a very "different" mindset  
behind the design decisions going on in xen, and it's being disguised  
as "code reduction".  I thought it was accepted a long time ago that  
the SLOC metric for simplicity and quality of design was about as  
useful as measuring the monetary value of a lump of gold by how it  
smells.

Can someone please stop sucking me into these dead end discussions  
about bad engineering in action?  (Stop adding me to CC: lines  
please).  I'm not on the mailing list, I don't use xen, and really  
could care less which way that project chooses to go.

---
Matthew Sottile (matt@lanl.gov)
Advanced Computing Laboratory (CCS-1)
Los Alamos National Laboratory
Los Alamos, NM 87545
Phone: (505)665-6057
Web: http://ddma.lanl.gov/~matt/

Re: a last comment on xml-rpc

[Ronald G Minnich]

Matt Sottile wrote:

> Can someone please stop sucking me into these dead end discussions  
> about bad engineering in action?  (Stop adding me to CC: lines  
> please).  I'm not on the mailing list, I don't use xen, and really  
> could care less which way that project chooses to go.


my fault matt, sorry, I put you on here since you're the s-expression guy.

ron

Re: a last comment on xml-rpc

[Daniel Veillard]

On Fri, Feb 10, 2006 at 05:38:31PM -0600, Anthony Liguori wrote:
> I've also written an XML-RPC interface to Xend in C using libxml2.  It 
> very little code and just works.  Granted, parsing XML is more painful 
> that parsing S-Expressions but there are so many libraries for so many 
> languages that XML parsing is really a nop.

  Did you push that code anywhere ;-) ?
I can think of 2 very different ways to do the implementation (tree + paths
or direct SAX2 event flow) and would probably end up doing the second one
though the code might be more complex. It might depends on the efficiency of
the Python side, it may not be worth shaving microseconds and kilobytes
on the C side if the Python side is one order of magnitude slower, in which
case the simplest C code would be best.

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/

Re: a last comment on xml-rpc

[Anthony Liguori]

Daniel Veillard wrote:
> On Fri, Feb 10, 2006 at 05:38:31PM -0600, Anthony Liguori wrote:
>   
>> I've also written an XML-RPC interface to Xend in C using libxml2.  It 
>> very little code and just works.  Granted, parsing XML is more painful 
>> that parsing S-Expressions but there are so many libraries for so many 
>> languages that XML parsing is really a nop.
>>     
>
>   Did you push that code anywhere ;-) ?
>   
Not yet, but I will be :-)
> I can think of 2 very different ways to do the implementation (tree + paths
> or direct SAX2 event flow) and would probably end up doing the second one
> though the code might be more complex.
I took the tree/path approach.  I wrote an XML-RPC parser before using 
libexpat and it was more complicated than it should have been.  Once one 
has a DOM structure it's a pretty straight forward recursive routine to 
marshal/unmarshal.
>  It might depends on the efficiency of
> the Python side, it may not be worth shaving microseconds and kilobytes
> on the C side if the Python side is one order of magnitude slower, in which
> case the simplest C code would be best.
>   
Yeah, that was my basic feeling about it :-)

Regards,

Anthony Liguori
> Daniel
>
>