[Seaside-dev] Re: [Seaside] Re: Metacello packaging

[Dale Henrichs]

Julian Fitzell wrote:
> (whew.... too long. if this keeps up, we'll have to wait until ESUG to
> do this in person :) )

Haha, I think we're getting close.

At this point I feel like I've made a case for splitting out the things 
that I thought could be split out and you are in favor of keeping them 
bundled ... your reasoning is sound and I don't think there is an 
absolute right and wrong here...my main purpose is to engage you in the 
decision making process and that has been accomplished, so I think we 
can leave the notion of breaking anything out into separate 
configurations behind us.

> 
> On Sat, May 29, 2010 at 9:36 PM, Dale Henrichs <dhenrich at vmware.com> wrote:
>> Julian Fitzell wrote:
>> 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.
> 
> I think Slime is quite fundamental to Grease from a developer's point
> of view. Because we can't reasonably test all valid behaviour, it's
> equally important to know the things you *can't* do. Would you feel
> differently if Slime was called Grease-Tests-Bad? That's how I think
> of it conceptually.

Haha, I don't feel any differently:), but I understand your point and 
that's the important part ... to you Slime and Grease are part of a 
single unit and _should_ be branded and treated together and that's 
enough of an argument for me.

I think that with Doru's experience we do need to adjust the group 
definitions within Grease so that it is possible to load Grease without 
bringing in Slime ....

So the questions become:

   1. Should Slime be loaded by default when loading Grease?

     If no, we can split Slime out into a group that is not loaded
     by default.

   2. Should Slime be loaded by default when loading Seaside3.0?

     If yes, that's easy to arrange.

     If no:

       Should Slime be included in one of the other Seaside3.0 groups
       like the development group _or_ do you want an independent Slime
       group so that Slime can be loaded "through
       ConfigurationOfSeaside30" _or_ do you expect someone to explicitly
       load Slime "through ConfigurationOfGrease"?

> 
>> 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
> 
> And also, 5. how hard is it for people to know where to look for stuff?
>  - if there are projects within a configuration you can look through the options
>  - how do you know where to start looking for other configurations
> that might work with the one you're loading?
> 
> And 6. how is the group of code branded?
>  - if the combined functionality is considered to be distributed
> together, it may make sense to have it in a single configuration
> 

Very good points!

>> So the first order decision would be are any of those chunks candidates for
>> separate configurations or not ... in your opinion?
> 
> I'm really just going on a gut feeling here, which is a dangerous
> place to be when I really don't know Metacello very well :). To me, if
> you have to namespace the configuration name (i.e. it's
> ConfigurationOfSeasideJavascript not ConfigurationOfJavascript) it
> feels a bit forced to have a separate configuration.
> 
> "Seaside" to me is more or less what we distribute in the one-click,
> so in my opinion most of the stuff you mention should be in
> ConfigurationOfSeaside, due primarily to 1, 5, and 6.
> 

It will be easier to split things out later (if ever) than to glue them 
back together again, so going with your gut feeling is the prudent thing 
to do.

>> What packages do you consider part of the Seaside-Base and where does
>> Seaside-Environment fit in?
> 
> :) Ah... Environment. That wart keeps changing. Looking at the
> dependencies right now, we seem to be in a state where I would
> basically consider Environment plus its dependencies to be "Base".
> "Base" should be everything that basically everyone uses and nothing
> that opens ports, registers applications, or pulls in extra
> dependencies. So no Tests, no dev tools, no OB tools, no examples, no
> welcome screen, etc. Arguably Base should *not* include Environment
> itself, but let's not get too complex for now.

Okay, I will take this (and your comments in earlier emails) as a 
starting point and flesh out the details and see if I run in to any 
questions or troubles and then we'll go from there...BTW, I plan to take 
a look at the initialization problems mentioned in separate e-mail...

> 
> So that's where I stand. I don't think my opinion is necessarily more
> relevant though: I certainly know the package structure well, but you
> know the packaging tool! And maybe a fear of multiplying
> Configurations is my own personal hangup.

I think that by the time we've carved the Seaside packages up into 
groups, we should have a better feel for whether separate configurations 
are called for or not...

Dale