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=2.4 required=5.0 tests=AWL,DNS_FROM_RFC_POST, 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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id F2530BBAF for ; Fri, 24 Oct 2008 11:11:45 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAAAHsuAUnRVcbgkGdsb2JhbACTOD4BAQEBCQkMBxEDpUmHSQEDAQODTYIB X-IronPort-AV: E=Sophos;i="4.33,476,1220220000"; d="scan'208";a="30692216" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Oct 2008 11:11:40 +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 m9O9Bb2s022580 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 24 Oct 2008 11:11:39 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAAAHsuAUnRVcbgkGdsb2JhbACTOD4BAQEBCQkMBxEDpUmHSQEDAQODTYIB X-IronPort-AV: E=Sophos;i="4.33,476,1220220000"; d="scan'208";a="30692180" Received: from rv-out-0506.google.com ([209.85.198.224]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Oct 2008 11:11:12 +0200 Received: by rv-out-0506.google.com with SMTP id k40so1373468rvb.57 for ; Fri, 24 Oct 2008 02:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=i5h/7pdpIGnPQwGm0CjIvUestnMuvhzUQ3pdIe+o+IY=; b=aZOhx7ALgjKnPjhUPFwvluntIw9UyTHMX0+ewOFCp6QaGgT/k2dKv+fXP0nHlr9Ovv SbpLRSYjcouuB9Bldn/hyB0gQLTMfG0eZr+ApU1RoM1isIrF0T5MzbPFvKJe1LkMM3Km v/kdJiq2U/2Z1OVihb2gSA1Vwycz5NOcJCk9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=xcmFE7WO4AlQhC8qCsm7YM1x0uqJU2JPEc021baQeoV04n68ey5p9M420+w6LyByke lD0FU32IikYoayl+e0+X0l1ywuL9KV0rqreNcpA8F3oMjuEUq2hegfuB8WrRH0EUePYm fkrTPV0OuDGK4zRwDZydAnowlQBj2Rcdhl71Q= Received: by 10.141.201.1 with SMTP id d1mr1028937rvq.117.1224839471007; Fri, 24 Oct 2008 02:11:11 -0700 (PDT) Received: by 10.141.41.10 with HTTP; Fri, 24 Oct 2008 02:11:10 -0700 (PDT) Message-ID: Date: Fri, 24 Oct 2008 11:11:10 +0200 From: "=?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?=" Sender: mikkelfj@gmail.com To: "Dario Teixeira" , caml-list@inria.fr Subject: Re: [Caml-list] Re: Serialisation of PXP DTDs In-Reply-To: <20081023233657.GE32611@NANA.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081023210527.GB32611@NANA.localdomain> <278256.11946.qm@web54605.mail.re2.yahoo.com> <20081023233657.GE32611@NANA.localdomain> X-Google-Sender-Auth: 8d6d0696f4371cfc X-Miltered: at discorde with ID 49019149.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; mikkel:01 rgensen:01 mikkel:01 pxp:01 dtds:01 overkill:01 abstraction:01 encodings:01 compiler:01 ocaml:01 ocaml:01 haskell:01 syntax:01 syntax:01 sexp:01 I guess this discussion is an overkill for the problem at hand, but speaking of binary extensible protocols, have you looked at ASN.1? It is an abstraction over any number of encodings. At least one binary encoding has extension bits to allow future growth of object collections and similar. Mikkel 2008/10/24 Mauricio Fernandez : > On Thu, Oct 23, 2008 at 03:21:01PM -0700, Dario Teixeira wrote: >> Hi, >> >> > This protocol definition is fed to the compiler, which >> > generates the OCaml type definitions, as well as the >> > encoders/decoders and pretty-printers (as you can see, >> > the specification uses a mix of OCaml, Haskell and C++ >> > syntax, but it's pretty clear IMO) >> >> Basically the XDR approach, but with a syntax inspired >> by more modern, functional languages, right? > > Yes, something like XDR (and Google's Protocol Buffers, and Facebook's Thrift, > and and :) with richer data types (algebraic and polymorphic types, etc.) and a > self-describing encoding that allows you to extend the type definitions while > ensuring interoperability. > >> > It's not a drop-in solution like sexplib's "with sexp", >> > by design (since it is meant to allow interoperability between >> > different languages), but it's still fairly easy to use. >> >> Personally, I think that a sexplib-like syntax extension is the killer >> feature for serialisation libraries, and the reason why I was immediately >> swayed by sexplib. However, writing a sexplib-like syntax extension for >> your serialisation library would entail solving the reverse problem now >> handled by your compiler. This might not always be possible because some >> features of Ocaml's type system might not map neatly into your format. >> Nevertheless, the sheer convenience of the syntax extension approach makes >> it worth while having, even if on occasion the preprocessor were to produce >> an error message stating that it could not convert a certain structure. For >> reference purposes, you could even have the syntax extension output to an >> external file the inferred structure definition in your language format! (I >> know this would be a very complex project, but it does illustrate the power >> of Camlp4). > > In fact, the wire format easily supports all of OCaml's type system (bin-prot > does, after all, and this is essentially a self-describing, extensible > bin-prot). I introduced limitations in the data schema to ensure extensibility > and portability. Any OCaml type can be encoded easily, but not all possible > changes to an OCaml type are safe with regard to protocol compatibility. Using > a separate language makes it easier to prevent altogether (by making them > impossible to express) or catch such errors. > > Leaving unsafe protocol modifications aside (which just means that you have to > be careful when you change a type), the approach you suggest (supporting only > a subset of OCaml's type system in a "with protocol"-style syntax extension) > seems very doable. However, sexplib seems to be the safest option for > convenient, more or less future-proof serialization in OCaml, for the time > being. > > Cheers, > -- > Mauricio Fernandez - http://eigenclass.org > > _______________________________________________ > 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 >