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 RAA24862; Thu, 29 Apr 2004 17:47:20 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA24870 for ; Thu, 29 Apr 2004 17:47:19 +0200 (MET DST) Received: from rabelais.socialtools.net (rabelais.socialtools.net [81.2.94.243]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3TFlISH031375 for ; Thu, 29 Apr 2004 17:47:18 +0200 Received: by rabelais.socialtools.net (Postfix, from userid 108) id 209EE232DB; Thu, 29 Apr 2004 16:47:17 +0100 (BST) Received: from socialtools.net (chaucer.socialtools.net [81.2.94.242]) by rabelais.socialtools.net (Postfix) with ESMTP id 0831B232DB; Thu, 29 Apr 2004 16:47:16 +0100 (BST) Message-ID: <40912369.6010301@socialtools.net> Date: Thu, 29 Apr 2004 16:46:49 +0100 From: Benjamin Geer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-gb, en, fr, it MIME-Version: 1.0 To: John Goerzen Cc: Richard Jones , caml-list@inria.fr Subject: Re: [Caml-list] Re: Common IO structure References: <20040428.004358.45522587.yoriyuki@mbg.ocn.ne.jp> <016501c42c73$24e64b30$ef01a8c0@warp> <20040428.015800.126758722.yoriyuki@mbg.ocn.ne.jp> <408EEE3E.7050008@socialtools.net> <20040428034415.GB19564@complete.org> <40902265.9040702@socialtools.net> <20040428214442.GE10198@excelhustler.com> <4090E597.1080603@socialtools.net> <20040429122305.GA6688@redhat.com> <40911AF6.7020105@socialtools.net> <20040429153538.GA14089@excelhustler.com> In-Reply-To: <20040429153538.GA14089@excelhustler.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on rabelais.socialtools.net X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Miltered: at concorde with ID 40912386.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 layered:01 api:01 buffering:01 api:01 instantiate:01 passing:01 compressor:99 java-like:01 unicode:01 unicode:01 standardized:01 underlying:01 bytes:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk John Goerzen wrote: > On Thu, Apr 29, 2004 at 04:10:46PM +0100, Benjamin Geer wrote: > >>This is why I'm pleading for a layered API, so that character encoding, >>buffering, compression, encryption, and any other optional processing > > But you do not need a Java-esque API to do that. All you need is a > standardized File object. You could instantiate one of these by opening > a file. Or perhaps by passing an existing object to the initializer for > a gzip decompressor or a Unicode processor. The key for me is that I need to be able to chain processing steps together, so that I can, for example, decompress gzip format and convert the result to Unicode, a few bytes at a time. This suggests to me that the gzip compressor and the Unicode processor should themselves be implementations of the standard File object, so I can wrap a gzip decompressor around an underlying data source, then wrap the Unicode decoder around the gzip decompressor. The advantage of this approach is that the Unicode decoder doesn't know it's dealing with a gzip decompressor; it only knows it's dealing with something it can read bytes from. I can then easily remove the decompression step if needed. And that brings us back to a Java-like approach. If you can think of a better way of accomplishing this, I'd love to see it. Ben ------------------- 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