Hi David,
I just browsed the IOHandle code and thought we could get a smooth
transition Monticello-compatible

1) load IOHandle and subclasses
2) add ioHandle instVar to FileStream Socket and co
3) never use ioHandle inst var directly but rather lazily initialize
ioHandle in accessor message
4) PUBLISH
5) redirect every prim message to self ioHandle
6) PUBLISH
7) clean code in FileStream Socket etc...
8) PUBLISH

However, first problem first: what is an ExternalObject ? (the
superclass of IOHandle).
The name itself could be ExternalResourceHandle If I guess intention...

Nicolas

2009/11/27 David T. Lewis <lewis at mail.msen.com>:
> 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
>
>
>