A variant of the streams idea

[Nathaniel Mishkin]

At Apollo, we've developed a system for extending the concept of "stream".
Basically, every "object" (read "file" if you're not familiar with the
Smalltalk/object-oriented view of the world) has a type and every type
has a "manager" (read "subroutine library") that contains one entry point
(procedure) for each "operation" (read "generic procedure") that the
type supports.

In the case of stream I/O (the typed object view of the world extends
beyond simple stream I/O), the operations are things like "read", "write",
"seek", etc.  Operations are grouped into "traits" (read "interfaces").
The stream I/O facility defines a set of traits including "IO" (contains
the basic I/O operations listed above), "Socket" (contains the 4.2bsd
socket operations like "bind", "connect", "listen", etc.), and "Pad"
(contains operations for manipulating windows).

User's can define new types, write their associated managers, install
them into the system (without having to touch existing system source
code), create objects of the new types and (lo and behold) have existing
programs that use the stream I/O interface (i.e. that call "read", "write",
etc.) work on the new objects.  Type IDs are 64 bits and unique, so there's
never a problem when moving objects from one system to another (as long
as you bring the managers with you).  Managers run in user state and
are dynamically loaded when needed.

As you might guess, there are lots of uses for this facility.  For example,
in the case of a DBMS, one simple facility you might want is to be able
to read the DBMS like a sequential ASCII file, independent of what its
real internal structure is.  This might not be appropriate or reasonable
for every database, but to take a simple example, today, you need a special
program in order to dump the contents of a "dbm(3X)" database file.  On
an Apollo, such files could be typed as being "dbm" files.  Then, you
could write a manager for the "dbm" type that implemented the IO trait
operations for that type.  (You can think of the manager as being a
different form of the special dump program.) After you did this, you'd
be able to run program like "grep" on the "dbm" files and get useful
results.

If you were really ambitious, you might want to define a new trait --
call it the "ISAM" trait -- that had operations like "seek_by_key" that
took logical keys (i.e. NOT byte offsets) as arguments.  (Currently,
only Apollo -- not users -- can define new TRAITS, but we hope to have
this fixed sometime.) The idea is that this trait could be supported
by different DBMS's, that you'd be able to write programs that used those
operations, and that those programs would work with different DBMSs.
Of course it's not clear that you could come up with a set of operations
that made sense to enough different DBMS's to be worthwhile.  (Consider
the question of what the term "key" means to different DBMS's.)  But
it'd be interesting to investigate.