configuration (was Re: [Seaside] odds and ends)

[Avi Bryant]

On 6/29/05, Julian Fitzell <julian at beta4.com> wrote:

> To be honest, since it's been nearly a year since I've looked at it I'm
> not even sure I can claim to fully understand it.  /But/, I'd like to
> give some thought before ripping it out.  One of the reasons we were
> adding the "site defaults" was because we had several related apps at
> UBC all uses many of the same configuration information (auth servers,
> passwords, redirection URLs, etc).  Now obviously you don't *need* to
> share these settings in one place but it would sure be nice to.  And I
> think the only reason we weren't using them at UBC is because we were
> still using seaside 2.3.  Actually, I may have had that config stuff in
> my branch, so the reason may just be that (a) I didn't get around to it
> before I left or (b) I still don't love the UI for setting up the
> configurations.

Yeah, I certainly remember what we designed the framework to support,
though it's kinda telling that after over a year we still aren't using
it there :).  Slightly off topic, but: I think the main reason for
that is that the way that particular deployment environment is set up,
all the configuration information is in fact set by a startup script,
that can obviously do whatever abstractions it wants in terms of
setting up variables for commonly used values and so on - but it gets
edited with pico rather than through the browser, so the framework
never comes into play.

Now, I do agree that it's important to have shared configurations with
defaults, and I generally like the way SystemConfiguration and the
defaults specified in code work.  The question is really more whether
we need the two-level default system we have now, where you not only
specify a package default in the code, but you can also override that
default in the image (at a site level), and then override it again at
the application level.  This is what introduces a lot of the
complexity in the system.  The other thing that adds complexity is the
ability to do multiple inheritance at every level.  I think that it
may be that all we really need is a) to use regular Smalltalk single
inheritance, in code, for sitewide defaults (WAAuthConfiguration
subclass: #UBCAuthConfiguration ...), and b) to only allow "multiple
inheritance" at the application level, ie, each of those config
classes only specifies their own little piece in isolation, but you
can add as many of them as you want for a given application
configuration.  The main thing this doesn't allow you to do is
precombine them, but I don't think there will be enough configuration
classes in use for any one application for it to be a big deal to add
them individually when setting up an image (you have to do that now
for things like StyleLibraries, for example).

Cheers,
Avi