ANN: XmlRpc-Light 0.4 - Now a server too

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

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

[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

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

[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,
Dave