Where Squeak is Headed [was: Module discussion]

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Tue Nov 12 00:53:06 UTC 2002


danielv at netvision.net.il wrote:
> I volunteer to be part of the updates stream group.

Noted. You probably have an email in your inbox about it all.

> A few comments about the future role of the update stream -
> 
> I think SqueakMap is right now a good way to distribute what we'd call
> goodies, and also many of the kind of larger tools/systems that used to
> be integrated in past directly into the image (speech synthesis, for
> example, as Connectors are now distributed in SM). 
> 
> People, as they post their work to SM are constrained, however, by
> various in the image.
> 
> Examples include:
> - applications posted on SqueakMap could appear in the open menu, if
> code for a dynamic open menu was in the image.
> - The FileList refactoring that's in 3.3a would allow the simple
> addition of packages that add entries to the FileList.
> - Many applications that use sockets could handle errors more gracefully
> if sockets threw exceptions instead of deciding to wait, or asking the
> user directly. 
> - Many packages could be more usable and useful if PluggableMorphLists
> were much faster, and allowed colored or bold items.
> 
> I think the update stream should now be used mainly to fix these sort of
> problems, rather than introducing new functionality, which would be
> better released through SM.

I think we all agree with this. It was pretty clear at the "modules
discussion" meeting at OOPSLA.

> This means a change in the criteria for inclusion of things in the image
> - the focus would be "does this make Squeak freer, removing constraints
> and complexity?". 

Exactly.

> It also means changes to our contribution process - the group
> maintaining the update stream will definitely not be able to know and
> judge the effect of changes on all packages. Feedback from the people
> that depend on/are affected by the change will become even more
> important. 

Right again. I have a little proposal brewing about this too.

> It may be a good idea to change the process formally - for example,
> deciding that changes will be considered for the update stream if they
> are endorsed/used by two maintainers of different packages. This will
> also encourage people to get and give more feedback

Yes.

> A second role for the update stream might be to incrementally remove
> existing applications from the image, once they find a maintainer and
> appear as complete packages on SM.

Right.

> Daniel Vainsencher

regards, Göran




More information about the Squeak-dev mailing list