Craig Latta wrote:
> 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.

Bueno! I thought it might be stable but wasn't sure due to your 
definition of alpha.

"""
alpha, meaning "this release doesn't implement all the scheduled 
features". I sometimes add to the current feature list during this 
stage, but never after (only to the next feature list).
"""


>>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.

Bueno!

>>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. :)

Good.

>>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.

That is the answer I was looking for.
Basically does it perform better than the Sockets in current use.

>>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).

Bueno! I think that is of tremendous value.

>>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.

Great! I might have to put my hand to the plow and give it a try.

> 	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.

I don't believe there is a "requirement" of One True Socket Framework.
But I do believe it would be of great benefit. It could/would reduce the 
effort to understand networking apps. At least that's my view from the 
outside.

> 	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.

Sweeeet!!! :)

I'll give it a download and start learning.

Thanks.

Jimmie Houchin