RE: Channel concept instead of simple Files

[Sander van der Wal <svdwal@xs4all.nl>]

On Thu, 11 Jan 96 8:06:14 EST acken@informatik.uni-kl.de (you) wrote:

> >  Date: Wed, 10 Jan 96 08:08:27 EST
> >  From: Mike Griebling <grieblm@trt.allied.com>
> >  
> >  Let's do it the Oberon/F way.  I'm all for compatibility with an existing
> >  implementation.
> >  
> I like your enthusiasm.  But I checked the WinOberon/F version I got
> (1.0), and their Files module is basically the one that Sander
> presented.  O/F doesn't offer the kind of flexibility I'd like to see.
> Does anyone know if there is a more recent version of O/F with an
> enhanced IO concept?

I don't know. I downloaded WinOberonF1.1, but the extracted files 
cannot be read without installing them, which I'm currently unable to.
 
> The text Guy quoted previously has one good point: It identifies three
> levels of abstraction in the IO process.  
> 
>   chunk of data, identified by a locator
>       |  (eg file, memory block, pipe, tcp/ip)
>       |
>       |
>   basic reader/writer operating on bytes
>       | (offer SetPos, ReadByte, ReadBytes, WriteByte, WriteBytes)
>       |
>       |
>   reader/writer to translate high level data into byte stream
>         (eg. binary reader/writer, text rd/wr, see Sander's Files module)
> 
> This concept allows multiple readers and writers on one piece of data
> (just like the Oberon System does it on files), and allows to
> distinguish between the simple access layer that doesn't know a thing
> about the byte stream being read or written, and the interpretation
> layer that transforms some bytes into useful data.

There is another factor to take into account, there is a difference 
between for instance a disk file and the keyboard.
When I read from a disk file I know I can reread it because all
the bytes in the file will stay there. Essentially a disk file is
persistent. The keyboard on the other hand is not persistent, as
soon as I read a byte the keyboard has lost it.
On both keyboard and disk file I can open a Reader, but the Reader
on the keyboard cannot be repositioned, while a Reader on a disk file
can be meaningfully repositioned and reread.

-- 
Sander        

We get to pick tools and equipment that suit the job.  We spend nearly all our 
time programming ART's computer's. (~P.J.Plauger: Programming on Purpose III)