[Seaside] install Seaside30 without OB?

[Julian Fitzell]

On Wed, Jan 5, 2011 at 12:41 PM, Dale Henrichs <dhenrich at vmware.com> wrote:
> On 01/05/2011 11:50 AM, Mariano Martinez Peck wrote:
>>
>>
>> On Wed, Jan 5, 2011 at 7:29 PM, Dale Henrichs <dhenrich at vmware.com
>> <mailto:dhenrich at vmware.com>> wrote:
>>
>
> ...snip
>
>>    It was decided over a long series of emails to create a 'Base' group
>>    that was the absolute minimum usable chunk of Seaside.
>>
>>    The 'Core' group was then defined as everything else that came with
>>    Seaside excluding the tests. Note that the core group includes all
>>    of the development tools as well...
>>
>>
>> Hi Dale. This is what is misleading for me. I mean, from my point of
>> view, development tools are not core. Just watching it form outside, I
>> may call 'core' to what you call now 'base' and try to find a better
>> name for what it is now in 'Core'.
>>
>
> I understand.
>
> We included the 'kitchen sink' in the 'Core' to just cut down on the number
> of options ... in other words if you _don't know what you want_ then you get
> everything ... if you know what you want then you load the 'Base' group plus
> the other packages that you need ...
>
> With regards to 'development tools', consider that many of the
> Seaside-Development functionality is really useful to have installed in a
> production image, so the distinction between development and production is
> not as clear cut as you might think.
>
> For example, the debugger-based error handlers are necessary to debug a
> problem that is showing up in a production even though they are part of a
> package called Seaside-Development.
>
> Also, without the 'Seaside Control Panel' (which requires OB and started
> this discussion)) it is more difficult to configure and control the various
> adaptors that you will be using... unless you really know what you are
> doing. So the 'Seaside Control Panel' is another one of those tools that
> you'd want installed in a production image....unless you know what you are
> doing
>
> So in the end, I think that 'Core'/'default' should stay the way it is, but
> perhaps the remaining packages could be grouped in such a way that it is
> easier to pick and choose functionality to be loaded with the 'Base' group
> when you really know what you are doing ...

Agreed, for what it's worth.

Julian