[Seaside] Re: Metacello packaging

[Julian Fitzell]

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

On Sat, May 29, 2010 at 9:36 PM, Dale Henrichs <dhenrich at vmware.com> wrote:
>
> 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.

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.

>From the point of view of someone loading Grease as a compatibility
layer for something they just want to run, though, clearly they don't
need Slime. They might not even need the Grease tests, of course.

I guess in my mind, for the average user choosing to load Grease, they
should be getting Slime included on any platform that supports it. But
there needs to be a slimmer set of packages (maybe it's just
Grease-Core itself) that projects which use it can pull in.

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

Agreed.

> 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

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

In my world view, I think 1,2, and 3 actually argue for keeping Slime
in the ConfigurationOfGrease. I can't see anyone using it without
Grease, I think people should be loading it when working with grease,
and its configuration is pretty simple, no? But that's just my image
of it - I'm happy to hear alternate views.

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

I mean, sure, I guess. But it's a single package, so why have a
separate configuration? And I still worry about 5. Ok, let me put it
another way: if it's an addon (and maybe it is), let's move it to the
Addons repository (actually, I'm liking that idea). If we're bundling
it by default in the Seaside distribution, I'd argue for keeping it in
the same Configuration.

> Comet could be called a group because of point 4.

I guess I'd make the same argument as for RSS.

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

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

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.

By the way, I changed the message subject and added seaside-dev -
probably best to continue the discussion there rather than on the
general seaside list.

Julian