| |
|
 |
|
 |
|
|
|
| |
|
|
xen-api
Re: [Xen-API] Typing in XML-RPC
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
|
|
|
| |
|
Home