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.6 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 5752EBB84 for ; Sun, 26 Oct 2008 19:15:20 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUBAIhQBEnRVciukGdsb2JhbACDI5AZPgEBAQEJCQwHEQOjd36GDwEDAQODTA X-IronPort-AV: E=Sophos;i="4.33,489,1220220000"; d="scan'208";a="16511456" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Oct 2008 19:15:20 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m9QIFJLS020009 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sun, 26 Oct 2008 19:15:20 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUBAIhQBEnRVciukGdsb2JhbACDI5AZPgEBAQEJCQwHEQOjd36GDwEDAQODTA X-IronPort-AV: E=Sophos;i="4.33,489,1220220000"; d="scan'208";a="16511455" Received: from wf-out-1314.google.com ([209.85.200.174]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Oct 2008 19:15:19 +0100 Received: by wf-out-1314.google.com with SMTP id 25so1995904wfa.0 for ; Sun, 26 Oct 2008 11:15:18 -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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7ALbP3EOyqoPUGKiVhVC0sdjvGdTjYboHJU/JwJjTc0=; b=SW6w4Kp1tJGDlSE5iIYI5QZS7VnXa2L8eYuBYqI2K7Ohuwsv+5Mu+cLEWU3p+JT6E9 cHryLp9/Nn1Lh+WA8vxzqpywmjSd0q02FdQclNDnZ9Tfsp0FoPGesHftJhe4aatzG/Ec t2bIikFiIYpweZiMsjhldTjJ20IXk07ZHTD+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=FjR5U8GNMwRghcgCLJZfnaeykPM3x7cmXnO0ZUop+HcWsD4uiO7NYg618i+UEFXmd5 D0GR9jD+0ZeU5EbnWo+4RHo6FZx7sggwS81KX5lLyxrYfXtjNCEQ/o6xgSuPhhrUIceI azUDOrWNE8q9mPdKuAi4eVOo9YupfDWR83pbI= Received: by 10.142.212.19 with SMTP id k19mr2189925wfg.13.1225044918126; Sun, 26 Oct 2008 11:15:18 -0700 (PDT) Received: by 10.143.35.6 with HTTP; Sun, 26 Oct 2008 11:15:18 -0700 (PDT) Message-ID: Date: Sun, 26 Oct 2008 14:15:18 -0400 From: "Markus Mottl" To: caml-list@inria.fr Subject: Re: [Caml-list] Re: Serialisation of PXP DTDs In-Reply-To: <20081025185824.GG32611@NANA.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081023210527.GB32611@NANA.localdomain> <278256.11946.qm@web54605.mail.re2.yahoo.com> <20081023233657.GE32611@NANA.localdomain> <20081025185824.GG32611@NANA.localdomain> X-Miltered: at discorde with ID 4904B3B7.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 trivial:01 runtime:01 subsumed:01 recompile:01 runtime:01 ocaml:01 trivial:01 ocaml:01 wrote:01 On Sat, Oct 25, 2008 at 2:58 PM, Mauricio Fernandez wrote: > Unfortunately, growing sum types is far from being the only protocol extension > of interest. There's a trivial extension which, I suspect, will be at > least as common in practice, namely adding new fields to a record (or new > elements to a tuple). bin-prot is unable to handle it adequately --- a > self-describing format like the one I'm working on is required. If you add a tag to a sum type, previous protocol implementations cannot read these values, whereas new implementations will be able to read both protocols. With records / tuples it is exactly the other way round: you could, in principle, read both in the old implementation, which just needs to drop new, unknown fields, whereas the new implementation requires these fields and hence cannot parse old protocols. I don't see how any approach could "hande" the respective unsolvable case. If a receiver doesn't know how to handle a tag, or if it requires data that is not there, you'll be stuck. Note, too, that even if you created an implementation which allows handling extended records in old protocols, this would undoubtly come at a pretty hefty cost. The only efficient way to do that would be to exchange protocols and generate code at runtime to translate quickly between protocols. I don't think it's worth it. > You might argue that this extension is subsumed by the ability to grow sum types, > since you can go from > > type record = { a : int } with bin_io > type msg = A of record > > to > > type record1 = { a : int } with bin_io > type record2 = { a' : int; b : int } with bin_io > type msg = A of record1 | B of record2 > > (Note how special care has to be taken to tag the record --- "explicit > tagging" in ASN.1 parlance.) This is surely a clean way to extend protocols without losing backward compatibility. > My design lifts that restriction and allows an old consumer to read the data > from a new producer when new fields have been added to a record or a tuple. I'd probably bet that simply putting a protocol translator in front of some old application you don't want to / cannot recompile would be about as efficient. Unless, of course, you go for the "generate efficient translation code from a new protocol specifications at runtime" approach, which seems very hard to implement. And it wouldn't even be as general, since an intermediate translator could translate between previously completely unrelated, arbitrary protocols (as long as you can define a meaningful translation). It's hard to imagine that anybody wouldn't want to use a type safe language with pattern matching (like OCaml) to specify that part... > AFAICS the ability to process data not understood in full requires the use of > a self-describing format like the one I'm working on. I'd go for the protocol translator. Especially if two protocols share a lot of structure, it should be trivial to define translations. Another very reasonable approach, which does not diminish performance, would be to exchange protocol versions. Assuming that one side is always more recent than the other, they should be able to support old protocols directly. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com