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

Julian Fitzell julian at beta4.com
Thu Jun 30 00:20:04 CEST 2005



Avi Bryant wrote:
> 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.

Well, in many ways I would still like to see the config info persisted 
in a declarative form so that administrators could safely manage the 
configuration with a web interface rather than mucking about in an 
imperative-format file where they have the full power of smalltalk at 
their fingertips.  Obviously there are advantages to being able to do 
this, but you will always be able to specify code in a startup file to 
override anything else that is provided so it's not like that's going to 
go away.

> 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

Well, again, I think it would be very nice for a system wide, 
non-programmer-provided configuration value to exist and is then shared 
by multiple applications.  Now, if we're running one image for every 
application--which seems to be the trend--then obviously the current 
system doesn't quite provide this (which comes back to persisting the 
configuration perhaps?).  So, it's possible that we're not currently 
meeting the goal, but I think it's very useful to have a concept of 
programmer-provided *safe* default, system administrator provided 
*useful* default, and application overrideable value.

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

I think you're probably right that multiple inheritance probably isn't 
essential all the way down.  Is it really more complex to have it 
throughout rather than simply at the last level, though?  If so, then 
I'm definitely not strongly opposed to that particular compromise.

Julian

-- 
   Julian Fitzell  --  Beta4 Productions
julian at beta4.com  --  http://www.beta4.com
Seaside: http://seaside.st/


More information about the Seaside mailing list