An analysis about a generic desktop application configuration management system

[Patrick Patterson]

On April 11, 2005 06:19 pm, Philip Van Hoof wrote:
> On Mon, 2005-04-11 at 17:55 -0400, Avery Pennarun wrote:
> > Um, are you not trying to come up with a *standard* configuration system?
> > It seems to me that there are lots of configuration systems that are not
> > the standard.  Developers of those systems don't need to ask for anyone's
> > approval.  They can do whatever they want.  That includes me, of course,
> > and I'm having a good time at it.
> >
> > But if you want to be the *standard* one, the thing you need absolutely
> > most of all is approval.  You should try your utmost to get it from
> > everyone possible.  People (not just Richard) are saying, rather
> > emphatically, that if depends on glib to run, they're not going to like
> > it.  You should pay attention to those people, whether you find them rude
> > or not.
>
> Yes, ok. You have a point here Avery. However. In order to get (for
> example) my attention or to make me want to listen to requirements,
> you'll need to at least try not to be rude.
>
> The project will most likely use a lot KDE technologies. What we are
> trying to do at this stage of the project is to collect the requirements
> and try match that with both technologies and solutions.
>
No, I think that we should have a checklist - the configuration system must do 
the following - list them, and make sure there is some form of protocol or 
high level API that everyone should follow - and then if someone wants to 
write a conformant implementation in ADA, they can.

So, if everyone leaves off putting implementation details "Must Use SQL 
Database X", and instead just simply says:

must support GET
must support SET
must support Iterators
must support transactions
must support notifications
must support ACL's
must have a backend and a front end
etc...
(the above is an example, but co-incidentally, isn't far off what the 
requirements that a lot of people who have actually written configuration 
systems have found they needed)

and everyone agrees - we can then move onto actually writing code...(or 
polishing and tweaking code for those of us that already have configuration 
systems that do just about everything that you could ever want to do).

I think that where we (as in the UniConf/GConf/KConfig/ACAP/etc. authors) get 
a bit nervous and excited is when someone says that we have to scrap 
everything and rewrite from scratch .. as long as we can all use the 
DBUS/Unix Domain Socket/TCP/etc. protocol to talk between the client and the 
servers (a point that I will admit is still up for discussion - at least I 
haven't heard everyone nodding and saying that is categorically the way they 
are planning to go), then it makes little difference what the actual 
implementation details are - the clients will still be able to get the config 
data, and I'll still be able to replicate it, and manage it how I want. :)

So, I would recommend that all technology answers get dropped until we've 
sorted out the questions that we need solved :)


-- 
Patrick Patterson
Technical Ambassador
Net Integration Technologies R&D