3.4 Road map and Refactorings (was: [Squeakfoundation]Order of business ...)

[Ned Konz]

On Friday 15 November 2002 02:11 pm, danielv@netvision.net.il wrote:
> Well, so far I got little response on the list to the 3.4 roadmap I
> proposed. Here's what I proposed:
> **********
> Applications that should be made removable and maybe removed -
>  - Celeste (I'll adapt to 3.4a and post the code for review in next
> few weeks)
>  - PWS (I've looked at Colins code, it looks fine except for some
> minor issues I'll address in an email soon)
>  - IRC (trivial)
>  - Scamper (volunteers? warning - requires starting to refactor and
> separate out some of the HTML/URL stuff in the image - not for the
> faint of heart ;-)

Should probably do this as part of the same project as integrating=20
Michael's/Stephen's sockets/flow code. URL stuff needs considerable=20
work (haven't seen Michael's stuff yet, though).

>  - Balloon3D (was made unloadable by Henrik in 3.3a - make sure it
> is now, too)

smaller stuff that should probably be unloadable:

- Sound synthesis/text to speech
- Speech-*
- Network-HTML*
- Stock fonts (nice to be able to unload them for license/shrinking=20
reasons, leaving a single font used for everything)
- Games (should be trivial)
- Obsolete or unused classes (DocLibrary and TarArchive come to mind)
- Genie configuration UI
- eToy peer-to-peer
- Nebraska

> Constraints on packages that should be removed -
>  - Sockets should be usable in a "quiet" mode, so they bring up
> exceptions instead of UI, letting the application decide what to do
> on time outs/problems.
>  - Make flaps pluggable, so applications can added their own
> prototype without disturbing the users existing stuff.
>  - PluggableListMorphs can and should be lightning quick, even for
> 10k item lists, and they should allow their items to be colored -
> this is usable by many, many packages (though the last might be
> better handled as an SM package).
> **********
>
> Got feedback saying they want Flow (via IRC), and MichaelR appears
> to be in the preemptive wish fulfillment business, depending on
> people helping him to test his stuff - it's a complete rewrite of
> the protocol sockets, so it'll take some serious testing.
>
> Anyone here know of other things that should/can enter 3.4?
> Probably not all of the above are going to happen in 3.4. Doug,
> have you decided what we're doing about the existing backlog?
> Luciano appears happy to help...
>
> About the process for refactoring applications out of the image, we
> bounced around some ideas and now have this sequence -
> *********
> * Code is refactored to make a complete package that requires no
> other code changes to load/unload.
> * Refactoring is posted for feedback (on list or SM) as needed.
> * When it's acceptable the code is inserted into update stream, so
> that code becomes removable using "remove category" in the simple
> case or DVS if there are class extensions.
> Then (Some unspecified time after the package starts living in
> SM...) * Update is issued that performs the remove, asking the user
> if he wants to reload from SM, or leave his version loaded (in case
> he has modifications).
> *********
>
> Comments on the process or it's clarity, or whatever are welcome.

Simple quality tests would be helpful for removals:

* Nothing left in Undeclared

* No more calls to unimplemented messages than there were to begin=20
with (preferably a lot less!) (do it: "Smalltalk=20
allUnimplementedCalls explore")

* No dangling refs to removed classes

* remove should unregister, and file-in should register, with Objects=20
tool, World menu, etc. as needed

--=20
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE