Hi--

	Luciano writes:

> I'd like to exchange some mails with you before Flow is fully
> integrated with Squeak.

	Sure thing!

> I've been using NetStreams a lot lately... but not with
> *External*Resources. I have almost finished a TCP/IP stack in
> Squeak...

	I'm very happy to see this complication. :)  Aside from the functional
niceness, I think this could be the best thing that has ever happened
for documenting the low-level TCP/IP details. I'm sure we can refactor
appropriately.

> I've also come with a set of Exceptions that I think are more
> appropiate for TCP and UDP: ConnectionRefused, NetDown, HostDown,
> ConnectionReset, OutOfBandData, etc.

	Cool.

> Another thing I don't like is using NetStreams with TCP sockets in
> the Listen state. Since a socket in Listen state can't bahave like a
> Stream, I think we should use completly different objects for that
> (ConnectionQueue, for instance, or just the TCPSocket alone).

	In design, I considered services related to accepting connections as
simply adjunct to sockets' main purpose (transferring data over
established connections), and not worth complicating the system
organization by implementing access to them outside the NetStream
hierarchy. In particular, I wanted to group all the socket-creation
messages that developers use in one place, so that people would
associate that place with the creation of sockety things of all sorts. I
like to minimize the number of classes people have to keep in mind to
use a particular part of the system, as long as it doesn't contort the
implementation unreasonably. I think this case works.

	In general, I'd for a developer's thought process to go something like:

-	I'd like to transfer something from one machine to another...
-	Ah, that's a streamy thing (having learned somehow of the "stream"
concept is the key that guides the developer to a solution), so I'll
look at class Stream.
-	Ah, there are several subclasses here for using different sorts of
transport (the "transport" concept is further described in the Stream
class comment), and one of them (SocketStream) has a class comment which
makes it seem appropriate to what I want to do.

	Having found SocketStream, the developer may then read about the
vagaries of TCP, UDP, listening, etc., from the methods and class
comments. (Note: I think the public release of Flow still has a single
NetStream class, whereas the current unreleased version has a
sub-hierarchy, roughly corresponding to transports. Also note that
netjam.org's website is temporarily down, pending my escape from ISP
hell.)

	What problem does the current organization present for you in use? Do
you mistakenly send inappropriate messages to listeners?

> BTW, please don't take me wrong. Everything I said was IMHO. I
> love Flow! I use it every day!

	(:  Whoo-hoo!

	I very much appreciate this and all feedback.

	Dave writes:

> I wrote IOHandle (http://minnow.cc.gatech.edu/squeak/996) some time
> ago as a way to separate the representation of external IO channels
> from things like FileStreams and Sockets.
> 
> [and on that webpage:]
> 
> I think that the IOHandle concept lines up more or less with
> Craig Latta's ExternalResource class... I was paying more attention
> to file handles than network handles, with the unix-like idea that all
> of these external things could be made to "look like" files.

	I have a similar consistency goal with Flow, to support all means of
transferring bits from one place to another (sockets, files, serial,
1394, MIDI, IR, etc.) I started with sockets since (at the time) it was
the thing I most needed that was completely missing from Squeak. The
next release has a new filesystem, and a streaming interface for speech
recognition and synthesis, amongst other things.

> My changes were made to the base Squeak image, not to Flow, so I don't
> know if this is useful. I would be happy to update it if either of you
> thinks it would help.

	If you're interested, I'd very much welcome improvements to Flow from
IOHandle.


	thanks!

-C

--
Craig Latta
composer and computer scientist
craig.latta at netjam.org
www.netjam.org
crl at watson.ibm.com
Smalltalkers do: [:it | All with: Class, (And love: it)]