An analysis about a generic desktop application configuration management system
ppatters at nit.ca
Tue Apr 12 01:35:45 EEST 2005
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
(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 :)
Net Integration Technologies R&D
More information about the xdg