[Squeakfoundation]Re: Flow integration

[Colin Putney]

On Thursday, November 21, 2002, at 06:56  PM, Craig Latta wrote:

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

This process would be appropriate for a monolithic image, but it 
doesn't fly very well in a modular universe. Flow can't co-exist with 
any packages which use the old networking classes, because they might 
be loaded after flow, or flow might not correctly patch them when it 
changes the names of the old classes. No matter how thorough the 
reference-fixing strategy is, there will always be some goofy package 
out there that got missed.

I'd like to see a migration process that went more like  this:

1) Rename some classes in flow and make it into a DVS package that only 
modifies the image by adding to it.

2) Carve out the existing networking code into a similar package.

3) Have a transition period where networking applications get 
registered on squeak map as depending on either old-sockets or flow. 
Make it known that flow is the "blessed" networking library and 
encourage package maintainers to port to flow. During this period, 
development of flow would be carried out in such as way as to maintain 
peaceful co-existence with old-sockets.

4) Once dependence on the old-sockets package has waned, remove the 
compatibility requirement and allow flow to evolve in whatever way 
seems ideal.

This process fits in better with the image factoring that the 
Mousekeepers have been discussing, and would make use of the tools that 
will be required for that anyway - package dependencies, versioning, 
conflict detection etc.

Notice that I haven't mentioned anything about what should be included 
"in the image." I think the factoring / packaging efforts will produce 
a multitude of image distributions, which can include either, neither 
or both networking libraries as appropriate.

My two bits.

Colin