re: Flow integration

Hi Andreas--
	
> From what I can see looking over the primitives, there are two things
> missing. One is support for socket options and one support for
> security stuff in file access. Both are not hard to add but can be
> painful if missing.

	Fair enough; I plan to implement those things for version 2.

> ...it'd be nice to have a version that doesn't put 82 classes into
> "reorganize me" - makes it really hard to grok this stuff for
> someone who has no idea how to reorganize flow ;-)

	Of course. This is an artifact of the way class categorization got, er,
attacked in Squeak 3.3 (in which I was working for quite a while),
before there was a stable 3.2. I think it was reasonable to leave things
this way for an alpha release (the current Flow release is 2 alpha). I
had planned proper categorization for 2 alpha 2. It'll be easier than I
thought, now that categorization support has emerged unchanged. :)

> Secondly, I am scared to death about the issue of backward
> compatibility.

	I think the best thing I can say to assuage such fear is that I've
already done "complete" installations of Flow into Squeak, in which I
removed *all* the old stream and socket (and file!) support, in three
days (24 hours' work), without incident.

	Nevertheless...

> I urge you to consider leaving the current streams and sockets
> basically intact and rather have flow be an _alternative_ to instead
> of a _replacement_ of the current classes.

	Yeah, that's why I currently distribute Flow that way. After installing
Flow, all Flow features and all old features work concurrently.

> From what I can see there are only very few places affected where
> global names collide and if that's the entire problem someone ought
> to be able to come up with a few alternative names.

	Actually, the current Flow release does this. Anywhere there's an
existing class with a name I want to use, I rename it with "Old"
prepended (e.g., "Stream" becomes "OldStream"). I also fixed all
references to those classes (as of 3.2 final).

	So...

> With the current version of flow you will instantly break any code
> that - for example - uses "FileStream readOnlyFileNamed: 'foo.bar'"
> or "Socket newTCP" (and believe me, there are plenty of those in
> Croquet...

	That's only true, possibly, for post-3.2final code; in the current
release of Flow I've fixed all appropriate class references as of 3.2
final. E.g., (FileStream readOnlyFileNamed: 'foo.bar') became
(OldFileStream readOnlyFileNamed: 'foo.bar'), and (Socket newTCP) became
(OldSocket newTCP).

	The new internal stream classes support the protocol of the old ones
completely. The other "name-stealing" ones (e.g., FileStream and Socket)
do this to a lesser degree. I decided it was easy enough to just fix all
the class references.

> ...if you need another instructive example just try to install flow
> two times ;-)

	That's not a fair example. :)  There's some very appropriate but
one-time magic in the Flow installer. Do you really need this
capability? It can be done.

> The entire situation here strikes me of being amazingly similar to
> the backward compatibility issues with modules - in both cases
> fundamental notions are being replaced instead of augmented. Let's
> try hard not to repeat this debacle.

	I think this situation is very different, since the new and old stuff
runs at the same time. We can be as gradual as we like in adapting
current applications to the new framework. Also note that, as has been
the case since Flow 1.2 (August 2000) no new VM is required (the new
primitives are in a plugin). For me, this is all in marked contrast to
the 3.3 modules experience; for example, class categories and pool
dictionaries just broke. :)  (This is not an invitation to reopen a
discussion on modules. ;)

> I'd be interested in finding out how feasable it is to implement the
> flow socket primitives in a non-threaded way. On PS/2 for example, or
> any *nix with broken pthreads. The code looks like it is relying
> heavily on a threaded implementation.

	Yes, it is, and I think that's a very good thing, from simplicity and
performance standpoints (see http://netjam.org/flow/advocacy.html). As
I've said before, I don't think it's worth compromising on either of
these points for the sake of supporting broken host platforms. I think
it'd be better to support those platforms by augmenting Flow's current
implementation. It seems quite feasible to me, by using Smalltalk
threads that simulate some of what the host threads do in the current
Flow implementation (not entirely unlike what happens in the mainstream
Squeak system currently).

	However, I do consider supporting the thread-capable platforms (e.g.,
win32, *BSD, Linux, Macintosh), which are overwhelmingly more widely
used than the others (e.g., PS/2, Acorn), a much higher priority. Flow
works on those popular platforms right now. And I think the work of
supporting the thread-impaired platforms now may be rendered moot in the
near future. I'm not familiar with the details of PS/2, but I know that
there are, for example, people working on pthreads for the Acorn.


	thanks,

-C

--
Craig Latta
improvisational musical informaticist
[email protected]
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]