Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 Apollo 11/21/85; site apollo.uucp Path: utzoo!utcsri!ubc-vision!uw-beaver!apollo!mishkin From: mishkin@apollo.uucp (Nathaniel Mishkin) Newsgroups: net.unix-wizards,net.database Subject: Re: A variant of the streams idea Message-ID: <2afa6c05.3166@apollo.uucp> Date: Fri, 27-Dec-85 12:37:19 EST Article-I.D.: apollo.2afa6c05.3166 Posted: Fri Dec 27 12:37:19 1985 Date-Received: Sat, 28-Dec-85 10:32:48 EST References: <2416@ukma.UUCP> <372@ncr-sd.UUCP> <964@brl-tgr.ARPA> <376@ncr-sd.UUCP> Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin) Organization: Apollo Computer Inc., Chelmsford MA Lines: 48 Summary: 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.