Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.unix-wizards,net.database
Subject: Re: A variant of the streams idea
Message-ID: <1039@brl-tgr.ARPA>
Date: Wed, 25-Dec-85 16:29:56 EST
Article-I.D.: brl-tgr.1039
Posted: Wed Dec 25 16:29:56 1985
Date-Received: Sat, 28-Dec-85 00:47:39 EST
References: <2416@ukma.UUCP> <372@ncr-sd.UUCP> <964@brl-tgr.ARPA> <2432@ukma.UUCP>
Organization: Ballistic Research Lab
Lines: 25
Xref: watmath net.unix-wizards:16241 net.database:162

> Why do you lose "seekability"?  Pushing a protocol on top of a file
> potentially brings in a whole set of ioctl()'s that can be performed.
> So lseek() becomes ioctl(fd, FLSEEK, offset) or some such.  Other
> operations can be performed with similar ioctl()'s.

By the time you have made open() slip necessary protocol
modules onto disk files, etc. you end up with just another,
kludgier, implementation of the UNIX file system.

Streams work as nicely as they do because they are modeled
as full-duplex pipes with protocol "filters" inserted into
the pipeline.  Stream data comes from somewhere and goes
somewhere.  Disk files just sit; there is no inherent "flow".
File data is not normally "consumed", for example.  Now,
FIFOs and pipes are a different matter, and indeed pipes are
implemented using streams on 8th Edition UNIX.

One could certainly add features to ordinary files.  I once
thought up one, which Mike Karels told me had already been
invented and called "portals".  This would be code associated
with a file that would "fire up" when the file was accessed;
not too different from the idea of attaching protocol modules
to files.  Something like this might be worth doing,
especially for databasing, but not by stretching the stream
I/O system beyond its basic model.