[Squeakfoundation]Re: Flow integration
Colin Putney
squeakfoundation@lists.squeakfoundation.org
Thu, 21 Nov 2002 19:42:50 -0800
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