Hi,

First, and concerning the more general problem of serialisation:
one often comes across a situation where a library encodes a very
complex and opaque value of type Foobar.t, but offers no dedicated
(de)serialisation functions.  The assumption is of course that users
can just use Marshal and be done with.  There are however situations
for which Marshal is badly suited.  Long term storage is one, and
portability is another.  Moreover, if the value is an object and you
wish to carry it across process boundaries, using Marshal is just
not possible.

Take also into consideration that the Sexplib syntax extension makes it
trivial to add (de)serialisers to a data structure.  The litmus test for
considering this task should be "is there any reasonable situation where
users of my Foobar library would like to serialise Foobar.t values in
a portable and long-term manner?".  If the answer is yes, I reckon it
wouldn't be too much to ask that the library adds support for Sexplib.

Note that in the paragraph above, "Sexplib" may be substituted by
another serialisation mechanism.  And this gets us to the question
of performance numbers you speak of.  In fact, besides performance I
would like to bring other variables to the table:

- ease of use
- "future-proofness"
- portability
- human-readability


Sexplib scores very good on ease of use, future-proofness, and
portability, and reasonably good on performance and human-readability.
My guess is that bin-prot has better performance but worse portability
and future-proofness, and nill human-readability.  Marshal gets
top scores in performance and ease of use, but fails miserably in
future-proofness, human-readability, and portability.

As for my particular problem with PXP DTDs, I will look at writing a
(de)serialiser by hand.  According to Gerd it shouldn't be too much
trouble.

Best regards,
Dario Teixeira






_______________________________________________
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

Reply via email to