[Seaside] [Fwd: Re: [Moose-dev] Re: why Glamour configuration is loading Refactoring and all the rest?]

[Dale Henrichs]

Julian Fitzell wrote:
> On Sat, May 29, 2010 at 12:32 AM, Dale Henrichs <dhenrich at vmware.com> wrote:
>> To directly answer your question...I agree, loading Grease should not load
>> Slime by default and yes, Slime can certainly be in it's own Metacello
>> configuration (not package:).
> 
> Looking at the Metacello chapter PDF that's circulating, it looks like
> what I meant was "project". Are you sure these things want their own
> configurations? It seems to me that Slime is "part of" Grease and all
> those other packages are "part of" Seaside, they're just not part of
> the core. Again, apologies if I'm just misunderstanding the
> terminology or the repercussions.

Project and configuration are very similar in meaning, When I say 
"configuration" I am specifically referring to a "ConfigurationOf package".

In my opinion I think that "these things" do want their own 
configuration. That is why I mentioned them:) However, the confguration 
vs group decisions should be made by the developers themselves since 
that structure influences how users of the configurations/groups view 
the project.

 From my perspective Slime is built on top of Grease rather than being a 
fundamental part of Grease. Grease is supposed to be a portability layer 
  and Slime doesn't implement portability methods. Slime is a tool that 
is used to analyze the portability of a body of code, but at the moment 
Slime itself has not been ported to either Squeak or GemStone nor is it 
_required_ for "Grease" functionality on the other platforms.

So from that perspective Slime could be separated out into a separate 
configuration without affecting the basic functionality of Grease as a 
portability layer.

In the end it is a judgment call as to when a chunk of functionality 
should be split out separately, because in terms of pure functionality 
the following two statements end up loading _exactly_ the same packages:

   ConfigurationOfSlime project latestVersion load.

   ConfigurationOfGrease project latestVersion load: 'Grease-Slime'.

The factors that I think drive one towards choosing a configuration over 
a group are:

   1. how independent is the chunk of functionality?
     - does the chunk of functionality have a utility outside of the
       original project?
     - does the chunk of functionality have an identity independent of
       the original project?
     - if either of the above are largely true, then a separate
       configuration may be a good choice
   2. how critical is the chunk of functionality to the project?
     - is it an option or an addon, where an "option" is something that
       you have to choose one from many and an "addon" is something that
       can be completely left off without affecting functionality?
   3. how heavy weight is the chunk of functionality?
     - an addon that is complex in terms of the number of individual mcz
       files or in terms of "required projects" may be easier to manage
       if it is in its own configuration
   4. how tight is the coupling of the chunk of functionality?
     - if the chunk of functionality is tightly coupled to the "core"
       then it makes sense to embed the functionality in main
       configuration

I think that you went through a similar decision process when you 
originally split Grease out from Seaside.

In my opinion Slime should be separated out for points 1 (outside 
functionality and independence), 2, and 3.

For the Javascript chunks (Javascript, JQUery, Prototype and 
Scriptaculous) I think the strongest arguments are points 2 and 3 ... I 
don't know about 4 as for point 1, they don't have much utility outside 
of a Seaside context so I would lean toward using a group with the 
caveat that point 3 could be a reason for moving them all into a 
ConfigurationOfSeasideJavascript...

RSS seem to me to be candidates because it is more like an addon.

Comet could be called a group because of point 4.

So the first order decision would be are any of those chunks candidates 
for separate configurations or not ... in your opinion?


> 
>> So if I add Slime to the list, then here are the projects that are currently
>> embedded in the Grease and Seaside30 configurations that should be broken
>> out into their own configurations:
>>
>>   - Javascript
>>   - JQuery
>>   - Prototype
>>   - RSS
>>   - Scriptaculous
>>   - Comet
>>   - Slime
>>   - Grease
>>   - Seaside30
>>
>> If that makes sense to you I can start building up the configurations (I can
>> do the work without interfering with current users) for your consideration.
> 
> I'd think you'd also want to be able to load or not load:
> Seaside-Base, Seaside-Development, Seaside-Admin-OmniBrowser,
> Seaside-Admin-Web, Seaside-Examples for a start. These functionality
> groupings don't seem conceptually any different to the ones above to
> me.

Once your past the configuration decision then defining groups to make 
it easy for users to make load/not load decisions.

What packages do you consider part of the Seaside-Base and where does 
Seaside-Environment fit in?

Dale