This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-API] Typing in XML-RPC
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Mon, 26 Jun 2006 09:34:08 +0100
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 26 Jun 2006 01:34:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <449C3D47.6070806@xxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <449C3D47.6070806@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
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 

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.


xen-api mailing list

<Prev in Thread] Current Thread [Next in Thread>