Re: re: Flow integration

[email protected] wrote:

>But please let us stop talking about choosing one before the other -
>let's aim at having them 
>*both* as packages so people can pick and choose. That is after all what
>we want, right?
>  
>
Is that possible? I can image two different loadable packages for 
networking, but I think the base image will include some kind of file 
system support, and then you'll have to choose between Flow or the 
current FileStream hierarchy. The same happens with Streams. I don't 
believe the Streams are ever going to become a loadable package, so 
we'll have to choose between the current Streams or Flow's,

The Guides will take the final decision, but if it was my call I would 
forget backward compativility and move Squeak forward. I have old code, 
and I know I might not have the time to port everything to Flow, but 
that's why we have a repository with old images. My old code runs 
perfectly in old images, and I don't expect it to run in newer images. I 
have used Flow in two projects:
- A TCP/IP stack, where the sockets are resources (polymorphic with 
Flow's ExternalResources);
- A framework for distributed agents (my "Army of Mobile Agents"). And 
in this project I implemented a hierarchy of ProxyResources: files, 
sockets and pipes than run thorugh a syscalls proxy... some form of RPC 
for system calls. All system calls are marshaled and executed in a very 
tiny server (~ 100 bytes) running on a different host.

This is my experience with Flow, and I believe Flow is simpler, cleaner 
and more useful than the Streams currently in Squeak.

IMHO, etc. Really :)
Luciano.-