[Caml-list] ANN: XmlRpc-Light 0.4 - Now a server too

[Dave Benjamin]

I have released XmlRpc-Light 0.4, an XML-RPC library for OCaml based on
Xml-Light and Ocamlnet 2. Source, downloads, and documentation are
available here:

http://code.google.com/p/xmlrpc-light/

This version adds support for writing servers. Two methods are currently
provided: CGI (based on Netcgi2) and Netplex. The obligatory hello-world
example looks like this:

let server = new XmlRpcServer.cgi () in
server#register "demo.sayHello"
(fun _ -> `String "Hello!");
server#run ()

To build a Netplex server, just change "cgi" to "netplex". An example of
a Netplex server including the required configuration file is in the
examples/adder directory.

All servers support the "system.getCapabilities" and
"system.listMethods" introspection functions, as well as the
"system.multicall" protocol. These can be disabled if desired by calling
the "unregister" method.

Other changes and improvements:

- The default date-time functions use the format
"20070729T10:42:00-07:00". This seems to be the most common
interpretation of ISO 8601 used in XML-RPC servers. You can override
this behavior by calling the "set_datetime_encode" or
"set_datetime_decode" methods on the client or server.

- Date-time parsing errors are now wrapped in XmlRpc.Error so that
they will be relayed to clients as faults.

- Error handling adheres much closer to the XML-RPC specification and
its list of suggested fault codes and strings.

- The client now sends a "text/xml" Content-Type header in requests.

Thanks to Gerd Stolpmann for the help with Ocamlnet!

Dave

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Dave Benjamin]

Richard Jones wrote:

> On Sun, Jul 29, 2007 at 10:51:17AM -0700, Dave Benjamin wrote:
>> - The default date-time functions use the format
>> "20070729T10:42:00-07:00". This seems to be the most common
>> interpretation of ISO 8601 used in XML-RPC servers. You can override
>> this behavior by calling the "set_datetime_encode" or
>> "set_datetime_decode" methods on the client or server.
>

> You might want to take a look at Julien Signoles' Calendar library for
> date/time types and handling:
>
> http://www.lri.fr/~signoles/prog/calendar/

I have this library installed, and indeed considered using it when I
began writing the date-time support. I would likely have used it, if
only it had the ability to parse strings.

I really wish Winer had considered alternatives to ISO 8601--say, UTC
epoch seconds--in the design of XML-RPC, because it's barely a standard
at all! There are so many variations and options that writing a parser
for it borders on natural language processing. Even the W3C suggestion,
which restricts ISO 8601 to a very small subset, doesn't help here since
it still conflicts with the common usage in XML-RPC, with hyphens
omitted between the date values. I decided to err on the side of
oversimplification, and support only the most common format, leaving in
hooks for users to customize the behavior as required.

There is still benefit, of course, in using a standard date-time type. I
only wonder if it is worth adding another library dependency; I am
trying hard to keep the list small (currently only Xml-Light and
Ocamlnet, which in turn requires PCRE). I think it would be great if a
date-time type were made part of the official OCaml distribution.

My only qualm with the Calendar library is that I feel a bit
uncomfortable with a top-level module called "Printer" that is for the
specific purpose of date formatting. I would assume that a module by
that name were for communicating with "lpt", if anything. But hey,
what's in a name, anyway... =)

Thanks for the advice. I will consider it.

Cheers,

[Dave Benjamin]

Daniel Bünzli wrote:
> Le 30 juil. 07 à 01:09, Dave Benjamin a écrit :

>> I really wish Winer had considered alternatives to ISO 8601--say, UTC
>> epoch seconds--in the design of XML-RPC, because it's barely a
>> standard at all! There are so many variations and options that writing
>> a parser for it borders on natural language processing. Even the W3C
>> suggestion, which restricts ISO 8601 to a very small subset, doesn't
>> help here since it still conflicts with the common usage in XML-RPC,
>> with hyphens omitted between the date values.
>

> Very unfortunate. He should have at least used RFC 3339 [1], which is
> akin to the W3C NOTE-datetime suggestion but a little more formal.

Even worse, despite the fact that the tag name is "dateTime.iso8601",
the XML-RPC "specification" only allows one official format:

YYYYMMDDTHH:MM:SS

The wording is vague, but it's clarified here:
http://www.effbot.org/zone/xmlrpc-errata.htm

"The time value is “naive time”, and does not include a timezone. You
can either use a fixed timezone in your application (such as UTC), or
ship the timezone offset as a separate value."

In other words, even though ISO 8601 clearly indicates *several* ways of
specifying a timezone, none are allowed by a standards conforming
XML-RPC library. As many have pointed out, a date-time value with no
time zone is useless, and assuming every server is using UTC is really
just wishful thinking.

In XmlRpc-Light, the default implementation reads and writes the format:

YYYYMMDDTHH:MM:SS+TZ:TZ

with the time zone offset optional on parsing, and mandatory on
generation. This seems to work everywhere but Ruby, where there exists
code to parse the time zone, but it apparently hasn't been tested in
awhile because it's broken. It's simple to fix, and I submitted a bug
report about it:

http://rubyforge.org/tracker/index.php?func=detail&aid=12677&group_id=426&atid=1698

So, now I'm faced with this dilemma:

Option A: Change XmlRpc-Light's default date-time handling to conform to
the XML-RPC spec. Interoperability with Ruby will work by default, but
time zone offsets will all be zero unless the programmer provides an
alternate, fancier date-time encoder/decoder.

Option B: Leave it alone. Time zone offsets will continue to work by
default. Ruby interoperability will not work without a code change on
one side or the other, at least until (and if) the Ruby team applies my
patch. Existing Ruby installations will be broken. XmlRpc-Light will be
considered non-conforming.

> I point you to this RFC because appendix A contains a tentative ABNF
> definition of ISO 8601 you may be interested in looking at.
> [1] http://www.ietf.org/rfc/rfc3339.txt

Thanks for the pointer. It's nice to see this explained so formally.
Maybe now would be a good time for me to learn how to use ocamllex.

Regards,