Re: [Xen-API] Typing in XML-RPC

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Fri, Jun 23, 2006 at 02:13:11PM -0500, Anthony Liguori wrote:

> One of the first things I noticed is that the spec defines some extended 
> types.  This is a bit challenging in XML-RPC.  It's unclear to me how 64 
> bit integer is represented (since XML-RPC only defines 32 bit 
> integers).  Also, defining void to an empty string is understandable but 
> requires some special casing that really shouldn't be necessary.
>
> Here's what I propose:
> 
> As a convention, we never use <struct>'s on the wire to directly 
> represent structures.  By convention, structs always appear as:
> 
> <struct>
>  
> <member><name>kind</name><value><string>[typename]</string></value></member>
>  <member><name>value</name><value>[typevalue]</value></member>
> </struct>
> 
> Where typename is the string representation of the type and typevalue is 
> the type-specific value.
> 
> Some common types would be:
> 
> struct - use this to represent actual structs.  typevalue is the normal 
> encoding of a struct
> long - 64 bit representation of struct.  typevalue is the string 
> representation
> void - use to represent None.  typevalue is ignored.
> 
> What's nice about this sort of consistent approach is that we can write 
> a marshalling/unmarshalling wrapper for Python that automagically does 
> this conversion.  Furthermore, if we did decide to support objects (as 
> the current spec does), we could automagically marshal/unmarshal these 
> over the wire.
> 
> The general idea here is that this is an extensible typing system for 
> XML-RPC.

I don't think that this is necessary, and it seems bandwidth-heavy.  What you
are implying is the transmission of type information along with every request,
but there's no need to do that -- the types are implied by the function calls
that are being made.  I think a better approach would be to marshall 64-bit
values as strings.  Each binding would then have to perform a strtol on it's
incoming values as appropriate, but I think that that's better than the scheme
that you propose, because of the bandwidth concerns.

It's not unreasonable to transmit void as the empty string, though I'd prefer
to use <nil/>, which is an "official" XML-RPC extension that a number of
people seem to be using already.  I don't know how far widespread that is
though, so using the empty string might be safer.

> Another thing to consider is having a type of exception.  I like 
> exception based APIs (i'll say that for another email) however the 
> format of the standard XML-RPC exception leaves a lot to be desired.

I agree that we should be using exceptions, and I also agree that the XML-RPC
exception specification is not great.  The document proposes using a string
array for exception code and parameters.  A binding for a language with
exceptions could then marshall those into first class exceptions, and that's
certainly the way I'd want to do it.

Ewan.

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api