Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!versatc!leadsv!laic!vogon!darin
From: darin@vogon.laic.uucp (Darin Johnson)
Newsgroups: comp.sys.amiga
Subject: Re: XPR External Protocols Standard
Message-ID: <611@laic.UUCP>
Date: 11 Jul 89 02:36:43 GMT
References: <18193@usc.edu> <12626@well.UUCP> <18362@usc.edu>
Sender: news@laic.UUCP
Reply-To: darin@vogon.UUCP (Darin Johnson)
Organization: Lockheed AI Center, Menlo Park, CA
Lines: 56

In article <18362@usc.edu> papa@pollux.usc.edu (Marco Papa) writes:
>At this point is clearly too late in the game. There are people already
>writing XPR-based external protocols. 1.4 Intuition supports IHooks, 
>another version of call--back technique,
...

In a similar vein, I had this wacky idea apropos to callbacks.

(hit 'n' now if you don't like off the cuff and stupid ideas)

I don't recall what made me come up with the idea, but after I thought
of it, it dawned on me that it is very similar to UNIX SYSV streams.

I don't know too much about streams, so pardon my BSD ignorance.
Streams, as the name implies, is a device driver that takes its input
(packets) and passes them to the output.  However, it supports
a protocol allowing you to specify a module to perform some actions
on the data while it passes through the stream.  In fact, you can
build up a whole list of these 'filters'.  The usefulness in this,
is that you can take an existing device, say a network connection,
and suddenly make it start doing something different, such as swapping
bytes, keep track of the number of reads vs. writes, etc.

I thought this would be a great idea for Amiga, but some ugly details
made me forget about actually trying to implement it.  What it
would do, is allow you to do some preprocessing on DOS
packets.  The 'stream' device would take a DOS packet, send it to
a module (a module could request a certain type), and that module
would fiddle with it and then send it on to the 'real' device handler.

Some examples (silly though they may be):

  A UNIX: device, that filters all open, examine, exnext packets so
  that "." and ".." in file names are interpreted.  Each UNIX device
  would be associated with something like DF0, etc.

  Even more extreme, a VMS: device that reinterprets the entire path!

  A kermit style device to translate open, write, read, etc. to a
  kermit protocol on SER:

  The PATH: device could possibly be written using something like this,
  depending upon how versatile the 'stream' device is.

The whole idea being, if you want to do something just a little bit
different than an existing device, you don't have to create a whole
new handler from scratch, just write some filtering routines.
I don't know if UNIX streams do this, but the filtering routines
could possibly stick around as a resident routine so that existing programs
could make use of the 'new' device.

By now, you all think I've flipped out.  Probably right.  Might be
worth pondering though, for you pondering types.

Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com)
	We now return you to your regularly scheduled program.