Hi Nicolas,

I honestly have not looked at this since before the Socket rewrite
in Squeak, so I know that there are some things that would need to
be reimplemented by now, at least for the Socket hierarchy.

ExternalObject is part of FFI. The class comment of ExternalObject is:

  External objects represent entities that are not part of the Smalltalk
  universe. They are accessed using a unique handle which is interpreted
  depending on the actual entity that is represented. 

  Instance variables:
	handle	<ByteArray | ExternalAddress>


That exactly describes what I was doing with IOHandle, so I plugged it
in there and used the handle ivar to hold the handle that maps to
the underlying data structures in the file and socket plugins.
Back then ExternalObject was part of the base image, so we might
would do it differently now (just add the handle ivar to IOHandle).

The loading was originally done with two change sets, which was necessary
because it was doing surgury on the StandardFileStream hierarchy at
the same time we were writing to the changes file. I'm sure there is
some way to do that with Monticello also.

Is there an interest in looking at this old stuff? I would not mind
spending some time to do an update that would work with Squeak trunk,
although it may be a week or two before I have time to get to it.

Dave

On Sat, Nov 28, 2009 at 02:42:14PM +0100, Nicolas Cellier wrote:
> 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
> >
> >
> >