Re: Configuration storage

[Ian Wells <I Wells tarragon-et co uk>]

Tom Tromey writes:
 > >> (I'm not a big fan of the current config interface, either, but I'm
 > >> not going to do anything about it...)
 > 
 > Ian> Actually, it's not *that* bad.  I think that if you did it as a
 > Ian> server, the keys' naming convention would become much more
 > Ian> flexible than the current /file/section/key form (which is only
 > Ian> really a convention in any case: there's nothing stopping you
 > Ian> stuffing up someone else's config file if you choose...).
 > 
 > There are problems with the current interface.  Generalizing the
 > namespace won't work with the current implementation (you can't have a
 > key which has both a value and subkeys).  You might argue that this is
 > an implementation problem.  I think it's actually somewhat fuzzy; for
 > instance you could write code that assumes the namespace is limited in
 > the way it is.

True enough.  You also have problems with the iterator functions
before long.

 > Also, there's no way to arrange to be notified of changes to a config
 > option.  If your config options are done via a remote server, this
 > would be a natural thing to do.  This has real effects on how
 > application code is written, so adding it later will probably be
 > painful.

Also true, though I wonder whether there's much call for this.

Another thing I thought of is that we're going to need a naming
service for objects before too long - you're better off bunging the
IOR of the naming service somewhere public than the IOR of everything
- so it might be wise to make this underlying configuration mechanism
a lot more general: first, let it have public, private and also
per-session objects and second, let it return any CORBA object for a
given key (which might usually be a string, integer or simple vector
type for a given item).

Of course, I could be getting carried away ;-)

 > Ian> I thought the 'less than nice' bit was mainly that they were crap
 > Ian> and inefficient, rather than working differently to ORBit.  If
 > Ian> that's the case, then why should their being crap stop us using
 > Ian> them, since we're effectively in the prototyping stage?
 > 
 > The problem is that using MICO in libgnomeui would mean every Gnome
 > application would require 48M of RAM just to link.  So it's not really
 > a technical problem but a perceptual one.

Good grief, I hadn't noticed that, although I've seen my memory
disappear as mico-c++ runs.  I haven't noticed the panel taking up
masses of memory, though, so I guess it's only a build problem at the
moment?

 > I actually think it is a reasonable thing to do.

I would argue that we shouldn't be frightened of sticking CORBA in
things now just because the implementation's complete crap.  That's
the point of prototyping (which is what we're talking about here) -
you don't try and do it well, you just try and do it.

-- 
Ian.