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=3.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, DNS_FROM_SECURITYSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id BD083BBAF for ; Fri, 24 Oct 2008 01:08:33 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjADAHKgAEnAXQImgWdsb2JhbACBdpF5AQEWIq8Lg04 X-IronPort-AV: E=Sophos;i="4.33,473,1220220000"; d="scan'208";a="19106734" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 24 Oct 2008 01:08:33 +0200 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m9NN8Xgk011050 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 24 Oct 2008 01:08:33 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjADAK+gAEnVBJXyb2dsb2JhbACBdpF5AQwKCwcPBa8Ug04 X-IronPort-AV: E=Sophos;i="4.33,473,1220220000"; d="scan'208";a="30678527" Received: from outmailhost.telefonica.net (HELO ctsmtpout3.frontal.correo) ([213.4.149.242]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Oct 2008 01:08:32 +0200 Received: from NANA.localdomain (83.59.9.219) by ctsmtpout3.frontal.correo (7.3.135) (authenticated as ferferse$telefonica.net) id 48F8E066002D824D for caml-list@inria.fr; Fri, 24 Oct 2008 01:08:32 +0200 Received: from mfp by NANA.localdomain with local (Exim 4.69) (envelope-from ) id 1Kt9I7-0004vc-E2 for caml-list@inria.fr; Fri, 24 Oct 2008 01:08:31 +0200 Resent-From: ferferse@telefonica.net Resent-Date: Fri, 24 Oct 2008 01:08:31 +0200 Resent-Message-ID: <20081023230831.GD32611@NANA.localdomain> Resent-To: caml-list@inria.fr Date: Fri, 24 Oct 2008 00:50:51 +0200 From: Mauricio Fernandez To: Gerd Stolpmann Subject: Re: [Caml-list] Re: Serialisation of PXP DTDs Message-ID: <20081023225051.GC32611@NANA.localdomain> References: <20081023163738.GA27707@usha.takhisis.invalid> <561320.93277.qm@web54606.mail.re2.yahoo.com> <20081023210527.GB32611@NANA.localdomain> <1224800330.7340.65.camel@flake.lan.gerd-stolpmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1224800330.7340.65.camel@flake.lan.gerd-stolpmann.de> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Resent-Date: Fri, 24 Oct 2008 01:08:31 +0200 X-Miltered: at discorde with ID 490103F1.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; pxp:01 dtds:01 0200,:01 gerd:01 stolpmann:01 donnerstag:01 ocaml:01 model:01 model:01 ocaml's:01 bindings:01 ocaml:01 hydro:98 wrote:01 extensible:01 On Fri, Oct 24, 2008 at 12:18:50AM +0200, Gerd Stolpmann wrote: > > Am Donnerstag, den 23.10.2008, 23:05 +0200 schrieb Mauricio Fernandez: > > I have been working for a while on a self-describing, compact, extensible > > binary protocol, along with an OCaml implementation which I intent to release > > in not too long. > > > > It differs from sexplib and that bin-prot in two main ways: > > * the data model is deliberately more limited, as the format is meant to be > > de/encodable in multiple languages. > > * it is extensible at several levels, achieving both forward and backward > > compatibility across changes in the data type > > > > You can think of it as an extensible Protocol Buffers[1] with a richer data > > model (albeit not in 1:1 accordance with OCaml's for the above mentioned > > reason). > > Have you looked at ICEP (see zeroc.com)? It has bindings for many > languages, even for Ocaml (http://oss.wink.com/hydro/). > > It is, however, not self-describing. Anyway, you may find there ideas > for portability. I've just taken a quick look at the manual (in particular, the definition of the Slice language and the Data Encoding section of the Ice protocol). Even though it solves a different problem, it looks very interesting --- both as a source of inspiration, as you say, and for its intended use as a middleware technology. Thanks a lot for the reference. Regards, -- Mauricio Fernandez - http://eigenclass.org