Matthew Fulmer asks: "Has this been superceeded by Flow? –Matthew Fulmer." Dave replies: Not exactly. IOHandle was intended as an enabling step in that direction, and Flow has broader and more ambitious scope. Flow would presumably replace this and many other aspects of current Squeak IO and stream handling.
IOHandle adds classes which represent input/output on external channels such as files or sockets. The FileStream and Socket hierarchies are modified to use IOHandle rather than to directly invoke primitives. Instances of FileStream or Socket collaborate with instances of IOHandle to separate streaming and protocol behaviors from behaviors related to external device and network access.
The purpose of IOHandle is 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).
If used with OSProcess, please update to at least OSProcess 3.0.4. OSProcess should be loaded prior to installing IOHandle (if loading OSProcess after IOHandle, just proceed through several error notifiers and all will be well).
These changes are not easily removed from the system, so please begin with a fresh copy of your image before loading IOHandle.
Old versions of IOHandle
Version 1.1.1 (December 2002) of IOHandle is http://swiki.gsug.org:8080/sqfixes/1244.html
My original (now out of date) posting is here:
IOHandle adds classes which represent input/output on external channels, such as files or sockets. The FileStream and Socket hierarchies are modified to collaborate with instances of IOHandle rather than directly call primitives.
I did this as an experiment to see if I could move the represention of external input/output connections into a separate class hierarchy, so as to take the responsibility for the IO connection out of classes such as Socket and StandardFileStream. This should help to unclutter the FileStream and Socket hierarchies, and simplify the job of refactoring these classes. I didn't bother to make an IOHandle subclass for AsyncFileStreams, but the same principle would apply.
I think that the IOHandle concept lines up more or less with Craig Latta's ExternalResource class (a better name for the idea, by the way). I was paying more attention to file handles than network handles, with the unix-like idea that all of these external things could be made to "look like" files.
It is still an open question in my mind as to whether a Socket should be collaborate with an IOSocketHandle, or if it should itself be a subclass of IOHandle. I lean towards collaboration, since the Socket classes contain a lot of behavior which is not directly related to the IO channel itself.
This change set should not be considered for inclusion in the Squeak image, as there are some machine dependencies and possible performance side effects that I have deliberately left in the code. It's just a proof of concept, but if folks think it's a useful direction, I can clean it up and make it suitable for real use.
