From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA29071; Fri, 10 Oct 2003 10:39:03 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA24856 for ; Fri, 10 Oct 2003 10:39:01 +0200 (MET DST) Received: from mail1.tpgi.com.au ([203.12.160.57]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h9A8cx100553 for ; Fri, 10 Oct 2003 10:39:00 +0200 (MET DST) Received: from 203-213-83-217-syd-ts15-2600.tpgi.com.au (203-213-83-217-syd-ts15-2600.tpgi.com.au [203.213.83.217]) by mail1.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h9A8bau09244; Fri, 10 Oct 2003 18:37:36 +1000 Subject: Re: [Caml-list] extending a type with Marshal From: skaller Reply-To: skaller@ozemail.com.au To: Ker Lutyn Cc: caml-list@inria.fr In-Reply-To: <20031008212257.19628.qmail@web40606.mail.yahoo.com> References: <20031008212257.19628.qmail@web40606.mail.yahoo.com> Content-Type: text/plain Message-Id: <1065775044.12729.14.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 10 Oct 2003 18:37:25 +1000 Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 ozemail:01 nastiest:99 font:99 marshalled:01 imho:01 marshal:01 marshal:01 parser:02 string:03 wrote:03 explicitly:03 fetch:03 upgrading:03 types:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 2003-10-09 at 07:22, Ker Lutyn wrote: > Marshal provides a convenient way to pass information between > components. It requires that types be the same at either end. But for > multi-machine production systems that must serve traffic continuously, > you cannot count on upgrading all your systems simultaneously. > If you have p2p connection: Negotiate. That's the traditional solution: used by modems, for example. Fixing a negotiation protocol isn't hard. IMHO the hard part is identifying 'versions' and 'capbilities'. Probably the best way is to use a string encoding (and use a parser). Nastiest example I can think of is requesting a font. Note this suggestion requires both servers and clients to maintain capability to handle several 'old' versions. This isn't extension of the Marshalled data, rather quite distinct data for each 'version' is possible, so the solution seems more general: the cost is extra handshakes -- how expensive that is depends on how long the agreement lasts (until explicitly refreshed? until end of session? only for a single data fetch?) ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners