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.8 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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id A1C5BBBAF for ; Fri, 24 Oct 2008 16:03:50 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcCAMxyAUnAXQIngWdsb2JhbACDJJAWPgEBFiKkQX2HOgEDAQODTQ X-IronPort-AV: E=Sophos;i="4.33,477,1220220000"; d="scan'208";a="16449867" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 24 Oct 2008 16:03:50 +0200 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m9OE3nvW021594 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 24 Oct 2008 16:03:50 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8AAH1yAUlKfS4cimdsb2JhbACDI5AWPgEBAQoJDAcPBaRDfYc9AQMBA4NN X-IronPort-AV: E=Sophos;i="4.33,477,1220220000"; d="scan'208";a="30708194" Received: from yw-out-2324.google.com ([74.125.46.28]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Oct 2008 16:03:49 +0200 Received: by yw-out-2324.google.com with SMTP id 5so302931ywh.27 for ; Fri, 24 Oct 2008 07:03:48 -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:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Zit8FP2JuWSzvjuSyBmHTWI8/O/hegj/qwkt7t63r8A=; b=Lw+F28Su2C3NpiH3IA/1ZvGswur0DiPJHit0zyCZD/DqZDuATcqOkE4Zht+H1FJ1F7 Yc3oLtgu4rVFKsx5ItJoO65Gnw//rsroIHBUX/murG+yeZV+GDN6313IcGh3Jo7loOio YbC7+omz2OpkCU2nLGyV3Xnk09HXihXB1VUes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DHbcF5JLemjQUKoN/DlWKuZE13ic0xbfSIDi2c8/RCFoDGpajVX9GkRqlNveq89Mlq bLiRVAuaEmgs+dWZTqwSYivn8sQBSPLyd3TdgA7XCeNF90zqPE1746K4uWPEIo3CRkn3 d67wxgshIDaCqx9wFq3tx33uuxpzuBFKxGkuM= Received: by 10.142.242.11 with SMTP id p11mr1021362wfh.174.1224857028048; Fri, 24 Oct 2008 07:03:48 -0700 (PDT) Received: by 10.143.35.6 with HTTP; Fri, 24 Oct 2008 07:03:47 -0700 (PDT) Message-ID: Date: Fri, 24 Oct 2008 10:03:47 -0400 From: "Markus Mottl" To: "=?ISO-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?=" Subject: Re: [Caml-list] Re: Serialisation of PXP DTDs Cc: "Dario Teixeira" , caml-list@inria.fr In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20081023210527.GB32611@NANA.localdomain> <278256.11946.qm@web54605.mail.re2.yahoo.com> <20081023233657.GE32611@NANA.localdomain> X-Miltered: at concorde with ID 4901D5C5.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 pxp:01 dtds:01 mikkel:01 rgensen:01 mikkel:01 overkill:01 abstraction:01 encodings:01 constructors:01 constructors:01 variants:01 On Fri, Oct 24, 2008 at 5:11 AM, Mikkel Fahn=F8e J=F8rgensen wrote: > 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. Note that it is perfectly safe to grow sum types with bin-prot. It was designed that way intentionally. It's just not safe to reorder or remove elements. Nobody needs to reorder elements, because it doesn't make any operational difference in the program. Backward compatibility of protocols you define necessarily requires the presence of old constructors in sum types anyway so you may not want to remove those in any case. There is hardly any harm from the protocol perspective in leaving old constructors in there. Note, too, that polymorphic variants even allow reordering with bin-prot. They are also generally safer, because they are always encoded as 32bit integers, thus making it extremely unlikely to get accidental "good" matches when reading incompatible protocols (at the expense of space and a tiny bit of performance). Except for human-readability, I think bin-prot should scale very well on the other requirements of serialization protocols once it has been ported to architectures with unusual endianness (almost all machines are little endian nowadays so hardly anybody on this list should be affected). Regards, Markus --=20 Markus Mottl http://www.ocaml.info markus.mottl@gmail.com