Mailing List Archive: Typing in XML-RPC

Typing in XML-RPC

Jun 23, 2006, 12:13 PM

Post #1 of 5 (2166 views)

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.

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.

Thoughts?

Regards,

Anthony Liguori

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

Re: Typing in XML-RPC [ In reply to ]

aliguori at us

Jun 23, 2006, 3:03 PM

Post #2 of 5 (2124 views)

Permalink

Here's an example implementation to further illustrate my point.

Regards,

Anthony Liguori

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.
>
> 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.
>
> Thoughts?
>
> Regards,
>
> Anthony Liguori
>
> _______________________________________________
> xen-api mailing list
> xen-api@lists.xensource.com
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Re: Typing in XML-RPC [ In reply to ]

ewan at xensource

Jun 26, 2006, 1:34 AM

Post #3 of 5 (2123 views)

Permalink

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Re: Typing in XML-RPC [ In reply to ]

veillard at redhat

Jun 26, 2006, 2:21 AM

Post #4 of 5 (2132 views)

Permalink

On Mon, Jun 26, 2006 at 09:34:08AM +0100, Ewan Mellor wrote:
> > 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.

Do we have a list of those error codes, or is this something which needs
to be defined, I don't think I saw them.

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/

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

Re: Typing in XML-RPC [ In reply to ]

ewan at xensource

Jun 26, 2006, 3:02 AM

Post #5 of 5 (2124 views)

Permalink

On Mon, Jun 26, 2006 at 05:21:25AM -0400, Daniel Veillard wrote:

> On Mon, Jun 26, 2006 at 09:34:08AM +0100, Ewan Mellor wrote:
> > > 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.
>
> Do we have a list of those error codes, or is this something which needs
> to be defined, I don't think I saw them.

No, we'll have to define them.

Ewan.

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

Mailing List Archive

Mailing List Archive

Attached Files: