Re: A proposal for a General Clustering Framework

[Alan Robertson <alanr@unix.sh>]

David Brower wrote:
> 
> Alan Robertson wrote:
> 
> > Unfrotuantely, XMLRPC is not nearly powerful enough.  I need to send
> > basically arbitrarily complex data structures back and forth.  It doesn't
> > have name/value pairs, or attributes, etc.  So, XML-RPC isn't very
> > attractive thing to build on for clusters...
> 
> I don't understand this conclusion at all.  You can have pretty
> much anything you want as a parameter, and XML is nothing but a big
> list of name value pairs.   The semantics of the parms (nvlist,
> attribute,
> etc. is up to the callers to agree upon; XML-RPC doesn't have an IDL
> that enforces any semantics.    And I don't know what kind of complex
> data structure can't be represented.  As with corba, you need to
> understand
> the abstraction to do linked lists or trees.  Since you can't send
> pointers
> (which are language dependant in all cases), you need to abstract the
> link references and resconstruct them in the appropriate way on the
> receiving end.
> 
> Someone else observed that xml-rpc was "an expensive round trip" for
> cases where one wished to use broadcast or multicast.   I think the
> approach to take is that used by one interpretation of the corba
> "oneway":  have the request contain a "no response needed" flag,
> so that the receiver doesn't send a message back.

According to the spec, XML-RPC is limited to the following data types:
32-bit int, boolean, string, double, date-time, base64, struct and array.

I certainly don't *think* that structs are intended to represent arbitrary
name/value pairs.  On the other hand, perhaps that was what was intended...
(?)

I had been thinking in terms of name/value pairs, lists, and strings.  I
suppose one could translate name/value pairs to structs with no damage
done.  Hmmm...  I don't think the interface needs data typing, but it
doesn't hurt anything except for message bulk - unless you need 64-bit ints
(which isn't that hard to imagine).

If you use XML-RPC for *all* your messages, typing is definitely a problem -
since it about doubles the size of messages over the simplest XML
representation, which makes it about 3 times the size of current heartbeat
messages - which are already thought to be too big...  I'm not fond of the
idea of compressing the messages just to get rid of text that could just be
avoided in the first place...

The spec only permits this being sent over HTTP, and there is no provision
for "event" messages which have not reply.  I suppose one could define
certain sets method names to mean "no-reply-needed".  Maybe they could even
be systematically named - for example with a "-nr" suffix on the name.

Maybe we could make the XML transforms be pluggagle, and allow the sender to
send either "strict" XML-RPC or a more compact XML representation...  If it
were hidden under the covers, no one need care...

	-- Alan Robertson
	   alanr@unix.sh

Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/