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