On Aug 24, 2005, at 7:00 PM, Dain Sundstrom wrote:
On Aug 24, 2005, at 6:29 PM, David Jencks wrote:
On Aug 24, 2005, at 6:10 PM, Dain Sundstrom wrote:
Could I add things rather than override?
No. You can do that in the console, but this file just lets
you
override certain attributes for GBeans that are already in the
server.
You'll notice in the sample there aren't full GBean definitions,
only what
amounts to attribute=value entries.
Would anything stop you from doing that though?
I would. The idea here is to allow a few attributes to be
customized locally even on a server with immutable configurations.
editing your configuration contents should use a different system.
Most attributes and all references will not be editable in this
config db.
I believe that this strategy is a bad idea. What is going to happen
is every time we release the software, someone is going to want to
tweak a setting that we either forgot to make manageable, or we
wrongly believed shouldn't be managed. Why not make all attributes*
manageable?
I think perhaps ones point of view on this argument has something to
do with whether one thinks small versioned binary configurations
should be the basic unit of distributing and building a server. If
you think that versioned binary configurations basically won't work,
then there is no reason to ever inhibit any editing of any
configurations, ever, since each server has no discernable
relationship to any other server. If you think versioned binary
configurations are the one true path, then you need some way to make
sure that the allowed modifications to a versioned binary
configuration are rather small and don't affect its' essential
character: otherwise the version stops meaning anything.
Personally I would like to give versioned binary configurations a
good chance to see if we can make them work: I don't think we have
tried them yet, and if they can be made to work I think they will be
a really cool feature. I would prefer to see "arbitrary edits" take
place using something like the console or a special tool, and only on
unversioned mutable configurations.
Excellent point. I think that shipping an experimental configuration
system as the default is bit risky. As a long term idea, I think that
a binary configuration system would be a good option, but I think in
the near term we should focus providing a tried an true text based
configuration system as the default.
Now the big question: Is can we deliver a text based configuration
system before 1.0 or should we expand on Aaron's configuration
overrider to fill in the gap?
umm, it seems to me that you are twisting reality here a little bit :-)
I think using anything other than the existing
known-to-work-although-sometimes-a-pain immutable binary configuration
system we have been using for a year+ is way too risky for 1.0.
Getting the very limited config db idea to work for a limited set of
easy to change attributes should eliminate much of the unbearable pain
of e.g. not being able to change the ports without excessive risk, I
hope. If not, I'm willing to live with not being able to change ports.
A text based configuration system is not possible IMO with the current
state of gbeans, where we have lots of complex attributes that really
need to be serialized. If we had nested gbeans or their equivalent a
couple months ago I would be much happier with the idea of text based
gbeandata serialization in the configurations.
thanks
david jencks
-dain
