2011/8/13 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> Hmmm, hard to remember...
> I started from a previous work of David Lewis.
> I think the main reason of the indirection was to connect
> - either a class with just an obfuscated handle - see (IOHandle
> makeNonviewableInstances)
> - or a class exposing structural details of the handle ByteArray known
> by the VM - I presume for debug purposes
>
> Then I stripped out the classes exposing details, and only XTIOHandle
> now does not seem that usefull indeed...
>
> Nicolas
>

This is confirmed by
http://www.squeaksource.com/XTream/SqueaXTream-OS-nice.1 (The
SqueaXTream experiments)
There was indeed an alternate

IOFileHandle subclass: #ViewableIOFileHandle
	instanceVariableNames: 'sessionID file fileSize lastOp'
	classVariableNames: ''
	poolDictionaries: ''
	category: 'SqueaXTream-OS'

ViewableIOFileHandle class
	instanceVariableNames: ''

"I represent an IO channel on a file system object, such as a file. I
keep a ByteArray
which corresponds to an SQFile data structure in the Squeak virtual machine. My
instance variables are updated to reflect the current value of this
data structure,
allowing the data structure to be indirectly viewed with a normal
Smalltalk inspector.

My implementation depends on knowledge of data structures in the
virtual machine.
For a safe implementation, use IOFileHandle."

and IOHandle was mostly a factory providing the indirection

IOHandle class>>makeViewableInstances
	"Instances can be watched with an inspector. This works for Unix and probably
	for Mac, but probably does not work on Windows, which uses a different SQFile
	data structure format."

	"IOHandle makeViewableInstances"

	ConcreteFileClass := ViewableIOFileHandle.
	ConcreteSocketClass := ViewableIOSocketHandle

For original work, see http://wiki.squeak.org/squeak/996

Nicolas


> 2011/8/13 Colin Putney <colin at wiresong.com>:
>> Hi folks,
>>
>> This is addressed mainly to Martin Kobetic and Nicholas Cellier,
>> who've done the Squeak port of Xtreams from VisualWorks, but I thought
>> I'd post here in case anybody else has an opinion to share.
>>
>> I've been working on integrating Filesystem and Xtreams, and I'm a bit
>> puzzled by the XTExternalResourceHandle hierarchy. In particular, I
>> can't figure out why XTIOHandle exists. It seems to have functionality
>> needed by XTIOSocketHandle, plus some indirection for hiding which
>> classes are used for file or socket handles, even though there's only
>> one choice for either of those. I'm guessing this has to do with the
>> need for Xtreams-Terminals to be VW-compatible, and that this
>> hierarchy is needed on VW.
>>
>> What I need to do is create different versions of XTIOFileHandle that
>> can provide access to data in alternate filesystems - in-image, inside
>> a zip file, on a remote host etc. Ideally, I'd extract the primitives
>> into a separate object, and provide alternate sets of "primitives" for
>> non-native filesystems. I don't want to get into changing things
>> without understanding the status quo, though.
>>
>> Thoughts?
>>
>> Colin
>>
>>
>