2011/8/14 Craig Latta <craig at netjam.org>:
>
> Hi Nicolas--
>
>> I note that the structure of Flow does not have the IOHandle level,
>> but have a zoo of sockets defined as ExternalResource
>> http://netjam.org/flow/architecture
>
>     The Flow streaming model has streams, and "resources" which provide
> the content for those streams (either internal collections or "external
> resources" like files, sockets, and serial ports). An ExternalResource
> in Flow has a handle instance variable, which is known to the virtual
> machine. Basically, I've gone for "has a" rather than "is a" where
> handles are concerned.
>

I think we are reaching a common agreement on such architecture.
(Too many years of maturation to my taste...)

>     In the interest of minimalism, it didn't seem necessary to model
> external resource handles as anything more articulated than opaque
> identifiers. Is something missing this way?
>

It sounds fair and that matches the ExternalResourceHandle of David pretty well
(which I recycled in Squeak flavour of Xtreams XTExternalResourceHandle ).
David had some variants for copying internal VM implementation details
of the opaque handle into some ivars for file and sockets,  but I have
abandonned this feature, and now have a void indirection level
XTIOHandle causing all this discussion...

>     I just updated [1-3]; thanks for reminding me.
>
>
>     thanks again,
>
> -C
>
> [1] http://netjam.org/flow/architecture
> [2] http://netjam.org/flow
> [3] http://netjam.org/flow/schedule
>

IMO the ExternalResource could be a common denominator used by various
Stream implementations.
I would not be amazed to see such class hierarchy both in trunk &
Pharo core before a few months.

This also makes me think to the work of Noury on Ocean - a FFI
interface on sockets.
To me, Ocean should just provide a variant of these external resources.

Nicolas

> --
> Craig Latta
> www.netjam.org/resume
> +31 6 2757 7177
> + 1 415 287 3547
>
>
>
>