An analysis about a generic desktop application configuration management system

[Richard Moore]

On Mon, Apr 11, 2005 at 06:35:39PM -0400, Avery Pennarun wrote:
> On Mon, Apr 11, 2005 at 11:23:42PM +0100, Richard Moore wrote:
> 
> > I agree notifications and network transparency would be nice. Certainly
> > for the former, adding support to KConfig would be easier than any change
> > of the underlying implementation.
> 
> Actually, I've personally ripped out and replaced all of KConfig's
> implementation to make it talk to UniConf instead, so I know quite a bit
> about how KConfig works.  (I don't know much about KConfigXT, but it seems
> separate from this question.)

Neat, did you try doing it as plugin backend?

> 
> I can say I'm pretty sure KConfig will mostly need to be redesigned - on the
> inside, not the API - in order to implement cross-process notifications. 
> The problem is that to get cross-process notifications, you'll either need a
> FAM-like thingy, a daemon, or at least broadcasts over something like DCOP. 
> All of these are major implementation changes that add up to about as many
> lines of code as KConfig already has.

I'm not sure you actually need cross-process, surely simply listing the
config files you're interested in is enough?

> 
> If you're going to rip the guts out and replace them anyway, you might as
> well replace them with an implementation that someone else already wrote and
> tested carefully.
> 
> Of course the API would also need to be slightly extended to allow you to
> register for notifications, but that would be backwards-compatible (you
> don't *have* to register if you don't care) and easy, so it's okay.

That could easily be added as a factory method that returns a QObject.

Cheers

Rich.