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