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

[Phil (list)]

Casey/Juan,

On May 25, 2012, at 10:05 AM, Juan Vuletich wrote:

>>> 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.
>>  
> 

Agreed... Cuis is Juan's baby that he's been kind enough to share with us.  While anyone is free to fork it as they can with other Squeak derivatives, that's not even on my radar as I think his sense of direction and priorities has been excellent.   I'm just trying to get clarity on where he/we see things heading.

> 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.

Nothing off topic or ranting about it.  You're quickly getting to the essence of what my original post was asking... and I like what I'm reading :-)  Your marketing (or non-marketing depending on one's point of view) has been perfect for me: you share what you've done in the form of clear and concise release notes and don't spend a lot of time talking up what can/might be but rather what is now.  UPOD at its finest!

> 
> 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.
> 

I've been on board with the original vision described and wasn't clear if that vision was starting to change.  It doesn't appear to be/have and that makes me feel better.

>>> 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;

My code isn't nearly that elegant so this probably won't be an issue :-)

> 
> 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.
> 

This is exactly what I was looking for re: clarity and am in complete agreement with these principles.  I have mixed feelings about formalizing this too much... on the one hand, it addresses my question.  On the other, formally adding it to the web page begins to add a process checklist that probably isn't needed yet.  I'm fine with keeping things relatively fluid and unless this starts to be a concern for other Cuis users, I'd rather not start burdening you or anyone else with what can turn into a bunch of administrative crap and slow things down.

>>> 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.
> 

Agreed.  I was simply throwing that out there as an option should the small image no longer be the priority.

>>> 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
> 

Agreed... see statement above re: administrative crap :-)  In closing, I think what triggered my original post was the excitement re: a lot of the initiatives being talked about raising a red flag in my brain that piling on features might become the new priority at the expense of keeping things small/simple/elegant.  Based on the comments from both of you, the concern appears to have been unwarranted.

> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Thanks,
Phil