2011/8/13 David T. Lewis <lewis at mail.msen.com>:
> On Sat, Aug 13, 2011 at 09:31:10AM +0200, Nicolas Cellier wrote:
>> 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
>
> There is a "home page" for my earlier IOHandle work here:
>  <http://wiki.squeak.org/squeak/996>
>
> The purpose of IOHandle is:
>
> * 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).
>
> Loosely speaking, you can think of this as analogous to the separation
> of file handles (the integer handle number) from streams (FILE *) in a
> C stdio library. By keeping these conceptually separate, it becomes
> possible to apply a given streaming behavior to more than one kind of
> low level IO channel. For example, you might want to have a stream
> that understands HTTP or how to decode a ReferenceStream, and it would
> be nice if that higher level stream worked properly regardless of
> whether it happened to be streaming over a TCP session, a file stream,
> or an anonymous pipe. It's hard to achieve that without some conceptual
> separation of the low level IO channel from the higher level steaming
> behaviors, and that is the purpose of IOHandle.
>
> Dave
>

Thanks Dave.
Yes the separation of Stream from the IOHandle is a good thing IMO.
Current architecture is
 - ExternalRessourceHandle
- - IOHandle
- - - IOFileHandle
- - - IOSocketHandle
The question as I understand it is whether the IOHandle level by
itself is required or not, and what does  it bring.
Maybe it could bring common behaviour between socket and files, but
currently it does not.
In current implementation the common behaviour is captured by the Stream level.

Nicolas

>
>>
>> Then I stripped out the classes exposing details, and only XTIOHandle
>> now does not seem that usefull indeed...
>>
>> 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
>> >
>> >
>
>