[Cuis] What gets included in the image vs. external packages

[Juan Vuletich]

Hi Folks,

Casey ransberger wrote:
> Inline.
>
> On May 23, 2012, at 7:40 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
>
>   
>> Lots of great discussion happening re: several things that will make Cuis even better.  
>>     
>
> It's been wonderful. Thanks to all present.
>   

Indeed. Thank you all!

>> However, it begs the question: what's the dividing line of what gets included in the base Cuis image vs. what should be external (possibly preloaded) packages?  
>>     
>
> Juan is the dividing line in my view. After Juan, the rest of us. For now, at least, he's a benevolent dictator and he's good at it, because he listens, he's patient, he's passionate about what he's doing, he works hard and with enthusiasm to help with the projects we do in Cuis, and he's flexible.
>   

Thanks for the nice words, Casey.

> Or: once you grok the design principles behind Cuis (the most important parts of which can be found on the web site,) it starts to be easy to know what goes into core and what doesn't. Does a solution provide valuable new functionality in an elegant way? Or does it simplify many other parts of the system, making the whole easier to understand and thus make use of?
>
> If we can make a study of these (and other) questions an intrinsic part of our culture, we will need only a group of core developers who understand the ideals and ethics behind what we're doing. As our community grows, this will become increasingly important (IMHO,) as the integration workload will only grow.
>   

Please forgive me for this rather off topic rant.

In the years I have been working on Cuis I never did marketing about it. 
I tried the Smalltalk community to be aware of it, but I never tried 
(too hard) to convince anyone. You might ask why. But I do want a 
community of Cuis developers (who develop Cuis and/or develop stuff with 
Cuis). I want an active, healthy and big community. But I also want a 
community of people who think alike. People who want (more or less) the 
same from the system. People who understand what makes Cuis different 
from the other Smalltalk systems and communities, and appreciate that. 
People who can usually agree quickly and easily about what to do.

Phil, what I mean, is that the I hope that the answer to your question, 
is that it will come out naturally. Folks, please check (again!) 
http://www.jvuletich.org/Cuis/Index.html . Please comment on what you 
disagree with, or you feel is missing. Having a concise and easy to 
understand project goal is very important for all this.

>> For example, I'm excited about the discussion re: mobile device support but, other than whatever minimal changes might be needed in the image to facilitate this support, I'd rather see this sort of thing as an external package(s) rather than baked into the image so that Cuis doesn't wind up having a similar set of issues as the other Squeak distros.  
>>     
>
> Find a way to do it in one beautiful class. Then we can easily convince everyone that it should be in the core;

Yes, something like that :) . These are some possible reasons to 
integrate something in the image:
- It belongs in the image conceptually, i.e. it makes sense to integrate it.
- It requires some refactoring of image code.
- It requires method overrides (method overrides are EVIL, the 
alternative is to refactor code to avoid them).
- It is a very small amount of code, that doesn't add too much 
complexity, but it simplifies and eases some bigger external package.

And these are some possible reasons to keep something as external packages:
- The developer(s) want to keep it outside, to have full control.
- It is application specific. The Smalltalk system (and dev tools) don't 
really need it.
- There are many alternatives implementations of the functionality, and 
it is better to let the developer pick one.
- It maintained elsewhere (for example, for Squeak, Pharo or some other 
Smalltalk system), or it is multi-dialect. Avoid code duplication!
- It is so complex that the complexity outweighs the usefulness for most 
people.
- It is in alpha state, not stable enough for regular use. (This is to 
avoid integrating half baked and later abandoned code).
- It includes a lot of code that is bad or poorly understood and not 
maintained.

Well, this is what I can think of right now. Maybe you can suggest 
additions / corrections. After a little discussion, this could go to the 
Cuis web page.

>> Maybe it makes sense for the 'default' version of Cuis to have many of these goodies installed, but if they were installed as packages it sure seems like it would be easier to get back to a base/core image for those who either need to go in another direction or just want a core image to play with.  I'm curious as to what the thinking is on this front...

I generally prefer a small image that can load goodies to a big image 
that can unload them. The reason is that once you load something in the 
image, nothing prevents other parts of the image to develop a dependency 
on it.

>> We've talked about shipping different versions of the image; perhaps a core image and a "full" image, but since everyone here is a developer at this point, I think it's still healthy for us to build our images ourselves: we'll find more bugs that way and it's DIY punk-rock. But that's just my opinion, and counter arguments are (of course!) quite welcome.
>>     

I agree. Besides, to have several images, we'd need several image 
maintainers. It only makes sense for a quite bigger community

>> Thanks,
>> Phil
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>     

Cheers,
Juan Vuletich