On Thu, Nov 26, 2009 at 08:56:08PM -0800, Colin Putney wrote:
> 
> I've been thinking about this too. For Filesystem, I've only  
> implemented very basic stream functionality so far. But I do intend to  
> develop its stream functionality further, and to go in a very  
> different direction from the existing design. Some design elements:
> 
> - Using handles to decouple the streams from the storage they're  
> operating on. The same stream class should be able to read or write to  
> collections, sockets, files etc.

I implemented IOHandle for this, see http://wiki.squeak.org/squeak/996.
I have not maintained it since about 2003, but the idea is straightforward.
My purpose at that time was to :

  * Separate the representation of external IO channels from the represention
    of streams and communication protocols.
  * Provide a uniform representation of IO channels similar to the unix notion
    of treating everything as a 'file'.
  * Simplify future refactoring of Socket and FileStream.
  * Provide a place for handling asynchronous IO events. Refer to the aio
    handling in the unix VM. Files, Sockets, and AsyncFiles could (should) use
    a common IO event handling mechanism (aio event signaling a Smalltalk Semaphore). 

Since that time I added aio event handling for file (AioPlugin, see
http://wiki.squeak.org/squeak/3384), which is a layer on top of Ian's
aio event handling in the unix and OS X VMx that which is mainly useful
for handling unix pipes. But I still think that a more unified view
of "handles for IO channels" is a good idea. The completely separate
representation of files and sockets in Squeak still feels wrong to me,
maybe just because I am accustomed to unix systems.

Dave