Re: [Caml-list] Long-term storage of values

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Freitag, den 21.03.2008, 14:37 +0000 schrieb Dario Teixeira:
> > No, there is a generator for that in Ocamlnet. ocamlrpcgen can be used
> > to generate these functions.
> 
> Hi,
> 
> If I remember correctly, the model with XDR+rpcgen is that the data type
> is defined in a special XDR notation, which ocamlrpcgen will then use to
> generate the Ocaml type and the (de)serialisation functions.  Though XDR
> offers a fairly rich type set, it's not quite as versatile as Ocaml's.

No, but it's ok. There are products, sums, sequences, and options. What
you cannot do is to marshal cyclic data - this is a limitation XDR
shares with most other external representations. There's also no notion
of objects.

> I just wonder if this will lead to situations where one would rather
> write the (de)serialisation functions by hand instead of relying on
> the poorer expressiveness of the automatic generators.

This may be an issue. Currently, ocamlrpcgen understands only a few
annotations that modify the O'Caml type the XDR type is mapped to. 

In the past months, I wrote Hydro, which is a library for another RPC
protocol called ICE. Hydro bases on my SunRPC efforts, and improves on a
number of its limitations. In Hydro, it is possible to annotate an ICE
type with an O'Caml function that converts it into a more pleasuring
representation. This allows to fix most shortcomings of the built-in
mapping to O'Caml types. Something similar could be done for XDR.

I wouldn't recommend Hydro for storing values, because its model is
OO-centric, and there is some impedance mismatch between the OO approach
and O'Caml's type system. Except you have cyclic values, because ICE can
represent that. (If you got curious: http://oss.wink.com)

> Btw, do you have any numbers concerning XDR performance?  My guess
> is that this would be the fastest method after Marshalling.

I don't have numbers. The O'Caml implementation is definitely slower
than the C code generated by rpcgen. However, the company I'm currently
working for uses this implementation for a high-performance cluster of
servers, and we never even thought about the XDR speed. It never
mattered.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------