Archive of UserLand's first discussion group, started October 5, 1998.

Re: Chuck's XML-RPC Comments

Author:Skip Montanaro
Posted:1/22/1999; 3:34:20 PM
Topic:Chuck's XML-RPC Comments
Msg #:2410 (In response to 2401)
Prev/Next:2409 / 2411

Here's my take on a few points.

* "text/x-xml-rpc2" as the media type. In the Zope list Jim Fulton commented that text/xml might be too broad for this specific application. I think trying to get new media types accepted will be difficult. It seems better to define a parameter, so the content-type would be something like "text/xml; service=XML-RPC". I don't know if there are predefined parameter names. This should be investigated.

* Endianness of . This doesn't matter since nubmers aren't represented using a binary format.

* Discovery of URI and MIME type. I don't think it's unreasonable to expect the client to know what URI to call for any given application server(s) it might be talking to. Similarly, XML should be the only MIME type supported (both for requests and responses). Allowing MIME types other than XML for the request and response will only make it difficult to write servers and clients. Lots of XML tools are coming online, so support shouldn't be a big issue.

* The elements of identifiers. I think the regular expression "[_A-Za-z][_A-Za-z0-9]*" is the only "safe" choice for identifiers. I'm not aware of any languages that won't accept them. Wherever possible you want the language binding to be as natural as possible. As an example, remote calls are made in Python by calling an attribute of a server object, e.g.:

server.latlong("San Francisco", "CA")

Those attributes have to be identifiers in the language. If it's extended to include unusual characters, you'd have to give up a little of the elegance of Fredrik's implementation with something like:

server.call("latlong", ("San Francisco", "CA"))

You'd also lose the ability to use nice features of the language like keywordarguments.

Perl uses a similar definition of an identifer (maybe the same). "$" is an introducer character that indicates that the object it introduces is supposed to be evaluated in a scalar context.

* fault mechanism. While perhaps a bit restrictive, I think it's adequate. I would like to see the faultString replaced (or augmented) by a more general faultInfo item that could be of any type that can be marshalled. It would also be nice to see some definition of standard fault codes. For example, I'd like to see codes 1-99 reserved for standard codes or assigned by an authority (much the same way that MIME types are allocated by whoever does that), perhaps similar to the sorts of exceptions that might occur in an application (divide-by-zero, segmentation fault/general protection fault, etc) and codes 100-599 be reserved for the standard HTTP response codes. I'd also reserve codes 600-999 on the assumption that HTTP will continue to get more complex and thus use more of those values. Codes 1000 and above could be free-for-all.

* timezones. I agree completely that dateTime objects have to reference a time zone.

Skip Montanaro (skip@calendar.com)

There are responses to this message:

This page was archived on 6/13/2001; 4:47:32 PM.

© Copyright 1998-2001 UserLand Software, Inc.