[Squeakfoundation]re: Flow integration

[Craig Latta]

Hi Andreas--

	Göran writes:

> Or am I missing something?

	You respond:

> No. Those are my points exactly. Thanks for summarizing.

	Not so fast... :)  I'd still like a response to my previous message to
you
(http://lists.squeakfoundation.org/pipermail/squeakfoundation/2002-November/000618.html,
and included below).

	It still seems to me that you've missed significant points in what I
wrote.


	thanks,

-C

***

> You fixed all references... you knew about.

	That's not the end of the process. :)  I think you're missing my intent
that those changes be temporary. The full integration process would go
like this:

1.	Change some of the original class names ("Stream" becomes
"OldStream", etc.)
2.	Fix references to those classes. Everything keeps working during the
rest of the integration process.
3.	Install new classes (several of which use the original names, and
provide backward-compatible protocol).
4.	Incrementally change the above references to use the original class
names again (references to "OldStream" become references to "Stream",
which is the new but backward-compatible implementation, etc.)
5.	The users of internal streams will see no cumulative change, since
the Flow support for internal streams provides complete backward
compatibility. The users of other support (e.g., sockets) can decide
whether to use the new or old framework.
6.	As we wish, we can incrementally remove the backward compatibility
and old framework support (perhaps over a very long period of time).

	The Flow 2a release implements steps 1 to 3, I'm proposing to finish
the process. Given this process, I don't think your analogies to 3.3
modules or Croquet (or Microsoft :) are valid.

> ...why not just keep the two hierarchies just completely disjunct?

	Because, e.g., I think what I call "Socket" should be called "Socket".
:)  As I see it, there is a genuine ontological conflict between the
current mainstream implementation and mine. And after renaming the
mainstream classes (which, for the reasons above, I think is no big
deal), they *are* disjunct. :)

	More seriously, I think it's very important to have the right names for
things. Sure, one normally makes a file stream by evaluating an
expression which doesn't refer to the actual instantiating class, but I
think the system is easier to use if people run into appropriately
evocative names for things in the system browsers, and this ease of use
is critical.

> Well if flow can't support those [thread-less] platforms at all...

	Um, I just said I think it can...

> ...just for the record - I am still waiting for benchmarks which
> actually indicate that flow makes any noticable difference in speed
> ;-)

	The reality of spare-time programming being what it is, if you want
*me* to provide these benchmarks, you'll have to be prepared to wait
until there are real applications I care about. :)

	Please remember that my primary motivation in designing Flow the way I
did was programming simplicity, not performance. It so happens that I
also think that it will also be faster. But I don't start profiling
things until they perform meaningful work. I haven't made time to write
applications yet, mostly because the ones I want rely on yet more
infrastructure that has little to do with streaming (how to store mail,
how to represent system changes, etc.). (I don't mean this as a dig
against, e.g., Celeste or Scamper, although I must admit I don't use
them.)

	But while you're waiting, please feel free to send tests that *you*
would consider meaningful. :)

> > 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).
> 
> This isn't quite what I meant.

	I know, but I stand by my answer. :)

> The question was more like: Is it possible to write an implementation
> of the socket primitives that adheres exactly to the specification of
> the primitives which may not use a threaded implementation?

	Sure, but I'd rather keep that simulation at the more malleable
object-memory level.

> Typically, it's best to stay compatible at the primitive level so that if
> there's a certain behavior expected by the ST code it should be able to rely
> on it.

	Sure again, but Flow's design allows that behavior to be provided
either by "auxilliary primitives" (which aren't called directly by
Smalltalk code) or by yet more Smalltalk code. I'd rather go the
Smalltalk route.

> At the very least I wouldn't expect people running on HP-UX (which
> IIRC, has horribly broken pthreads) to expect that they have to
> "reprogram flow" in order to get something to run which works
> perfectly well on Linux.

	Right, they wouldn't. Squeak would know what platform it's on, and act
accordingly.

	By the way, HP-UX has had perfectly fine pthreads since version 11.0
(two years ago). (Before that, it had DCE threads, which were indeed
problematic.)

> ...there are lots of platforms that Squeak can run on and some of
> them already have and more will have networking capabilities [but
> not properly functioning threads]. And I don't want to arbitrarily
> limit those...

	As I said, I think we can accomodate those platforms too.


	thanks,

-C

***

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