[squeak-dev] Xtreams file handles

mkobetic at gmail.com mkobetic at gmail.com
Sun Aug 14 18:33:54 UTC 2011

"Colin Putney"<colin at wiresong.com> wrote:
> Date: August 14, 2011 2:57:21 AM
> From: Colin Putney <colin at wiresong.com>
> To: "The general-purpose Squeak developers list"<squeak-dev at lists.squeakfoundation.org>
> Subject: Re: [squeak-dev] Xtreams file handles
> On Sat, Aug 13, 2011 at 8:22 AM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
> > 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.
> That's exactly right.
> And here's one other thing I just noticed: IOSocketHandle isn't being
> used at all. Socket itself serves as a handle for Xtreams that read or
> write to the network. I guess there's no reason not to make the
> changes I need.

It sounds to me that there is at least a partial overlap of responsibilities between "Handles" and what we call "Terminals" in Xtreams. A terminal stream is meant to smooth over the differences between various kinds of "sources" or "destinations" to provide a common "streaming" facade. But there aren't any hard rules about the implementation, if there is a suitable "handle" hierarchy that can already eliminate any significant differences, there's nothing wrong with having a single terminal stream taking advantage of that. But if there isn't such a thing available, having different terminal streams for different things is fine too. In VW we ended up with an ExternalRead/WriteStream which handles sockets and pipes and separate FileRead/WriteStream for files.


More information about the Squeak-dev mailing list