Hi Jimmie--

> From browsing it looks like Flow is still Alpha.

	I'd call it final at this point, no problems in the last two years.

> Has it been tried in a 3.7 image?

	I'm using it in a 3.6.5424 snapshot, which I think is equivalent as far
as this stuff goes.

> I read your comparison between Flow and Squeak's sockets. Its an
> older article. Is it still accurate concerning Squeak's socket
> rewrite?

	The primitive interface hasn't changed, so all those comments still
apply.

> Spelunking in Squeak's Socket code leaves me scratching my head.
> We have Socket, OldSocket, SocketStreams, OldSimpleClientSocket...
> I know two of those are sub-classes.
> 
> I might misunderstand what I see, I am far from knowledgeable. But
> it seems like Squeak's socket situation could use some consolidation.

	Yes. :)

> And where does Flow fit into the above?

	I think the Flow advocacy page still makes that case well (
http://netjam.org/flow/advocacy.html ). Basically, it replaces a lot of
messy and broken stuff. There was some resistance before about the cost
of adapting applications to it, but, to me, the "socket rewrite"
experience shows that there's not much one can do about that. :)  Also,
adapting applications that already use stream interfaces (e.g., those
that use Michael's work)

> How well does Flow perform?

	What terms are meaningful to you? It performs very well in my own work
(as fast as is possible with each host OS, I suspect). From a
theoretical standpoint I think it should perform better than the
official stuff (see the advocacy page again), but I haven't done a
thorough benchmark comparison.

> Would web apps be improved with Flow?

	They would be easier to write and understand (these are the things I
see as the main benefits of the design).

> How hard to migrate to Flow?

	It isn't hard. Writing applications to use streams instead of explicit
collection copying is much easier, actually. And adapting applications
that already use streams (e.g., those that use the "socket rewrite") is
pretty easy.

	To some degree, having a system based on a minimal snapshot makes this
issue moot (which was part of my motivation for developing the minimal
system :). There can be any number of socket frameworks; they'll just be
modules which can be loaded and unloaded at whim. In the particular case
of Flow, it coexists with the other two socket frameworks (since it uses
a dynamically loadable virtual machine plugin for its primitives), so I
don't see any great need for there to be One True Socket Framework. :) 
I do think, though, that Flow is the easiest to use, which is why I
advocate it.

	Also keep in mind that Flow does more than sockets (files, MIDI,
speech, etc.), and it does all that stuff in a consistent way, which is
nice.


	thanks,

-C

--
Craig Latta
improvisational musical informaticist
craig at netjam.org
www.netjam.org
[|] Proceed for Truth!