From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id F293EBBCA for ; Fri, 21 Mar 2008 17:04:01 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkAAFV540fU4367mWdsb2JhbACBWo80AQEBAQEIBQcJFpg9AQ X-IronPort-AV: E=Sophos;i="4.25,536,1199660400"; d="scan'208";a="10537783" Received: from moutng.kundenserver.de ([212.227.126.187]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Mar 2008 17:04:01 +0100 Received: from gate.lan.gerd-stolpmann.de (dslb-084-059-108-044.pools.arcor-ip.net [84.59.108.44]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1Jcjiq2Y9c-0002K7; Fri, 21 Mar 2008 17:04:00 +0100 Received: from [192.168.0.32] (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 47166C113; Fri, 21 Mar 2008 17:04:00 +0100 (CET) Subject: Re: [Caml-list] Long-term storage of values From: Gerd Stolpmann To: Dario Teixeira Cc: caml-list@yquem.inria.fr In-Reply-To: <905079.47901.qm@web54602.mail.re2.yahoo.com> References: <905079.47901.qm@web54602.mail.re2.yahoo.com> Content-Type: text/plain Date: Fri, 21 Mar 2008 17:04:52 +0100 Message-Id: <1206115492.8488.16.camel@flake.lan.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19G7rABPW2+67TO/kvZzR5iHrxa9WzQ3cK/XFb 6TdsG5kpUKpKJ3/3K7fdao4CMH19uHU+to893h4lchdCOzCMWC bgVBTq4a1ujVHbEBxmamdBGLuwX3Rl8 X-Spam: no; 0.00; gerd:01 stolpmann:01 ocamlnet:01 model:01 notation:01 ocaml:01 ocaml's:01 annotations:01 o'caml:01 o'caml:01 model:01 mismatch:01 o'caml's:01 marshalling:01 gerd:01 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 ------------------------------------------------------------