Colin Putney wrote:
> One, lets not conflate these two issues. Including Shout is unrelated to 
> removing Services; either could be done without the other. Let the two 
> proposals stand or fall based on their merits.

Yes, good point.

> Two, removing Services sounds like a good plan. For services to be 
> really worthwhile, lots of other stuff would have to be rewritten to use 
> them. That hasn't happened, and it looks like it never will. Services 
> should be easy to make into a loadable package, so if any other packages 
> out there happen to use it, they can keep doing so.

My thoughts exactly.

> Three, I'm a little ambivalent about Shout. Syntax coloring is cool, but 
> it seems to sink its tentacles fairly deeply into Morphic. 
> Understandable, given that it must respond to every keystroke. I'm in 
> the middle of reworking the Shout support in OmniBrower, to break the 
> dependency it introduces between the Smalltalk domain model and Morphic. 

Ah. I think I wasn't clear here. The goal is to provide syntax 
highlighting hooks directly in SmalltalkEditor (see the earlier 
discussion about the SmalltalkEditor/TextEditor distinction). These 
hooks just happen to look a lot like the extension methods Shout uses 
today ;-) But by the end of the day, all you will need from Shout are 
the categories Shout-Parsing and Shout-Styling and you will get 
highlighting without extra dependencies. If you happen to write an 
alternative package that can be utilized with the same protocol you will 
be able to hook this in seamlessly. And if you think that syntax 
highlighting is a waste of memory, you can just unload Shout.

> These aren't really show-stoppers, but they make me think that it would 
> be better to keep Shout as a separate package, with really clear 
> boundaries. Maybe someone who knows Shout better could convince me 
> otherwise, or come up with a way to have Shout in the kernel image that 
> would keep it separate from the default toolset, available to alternate 
> toolsets such as OmniBrowser, and easily unloadable.

That is the goal.

> Finally, we ought to have some sort of policy or philosophy for deciding 
> what is included in the base image. Are we still trying to create a 
> minimal image that can be bootstrapped up to a more complete image? Are 
> "extras" eligible for inclusion if they have broad enough appeal?

Great questions. I've been waiting for people to propose things they'd 
like to see in Squeak (assuming that they are also willing to work on 
them). And although I think we'd all like the image to get smaller, more 
compact and simpler, I don't think we should exclude anything before 
discussing it concretely. So yeah, I'd think that if people have stuff 
that is broadly desirable, please do put it forward.

Cheers,
   - Andreas