Re: GConf Sources and notifications.

[Havoc Pennington <hp redhat com>]

On Tue, Mar 25, 2003 at 03:00:46PM +0000, Dave Cridland [Home] wrote: 
> Damn, that breaks an ACAP backend completely. I'm honestly thinking the
> best way to tackle ACAP support is to actually write a new gconfd -
> trying to get ACAP into the existing framework, which was essentially
> designed for dumb, single-user access, backends, looks close to being a
> non-starter.

Could work, you just have to think about how to handle the case where
there's no ability to set up a systemwide server. Do you fire up your
ACAP server in place of gconfd then? Basically what you're talking
about is replacing gconfd with acapd, or using ACAP rather than CORBA
as the gconfd protocol.

> I can get a buggy backend in place, but gconf clients (as in, apps) will
> end up out of sync if they unset a value, or if anyone else sets one
> from another machine, rendering the entire point of an ACAP backend
> worthless.

Why would that be, if we move the notification code down a level into
the backend?

gconf is basically just a big series of layers that look pretty
similar:

 GConfClient -> GConfEngine -> CORBA -> GConfDatabase -> GConfSources -> GConfSource -> backend

(around Red Hat we call this the "lasagna" design pattern; like
spaghetti code, but layered instead of all mixed up ;-)

So right now the notification is at the GConfDatabase level, it needs
to be kicked down to the backend, then on the GConfSources level you
have to analyze the notify to see if it actually changes the
app-visible value and emit a notification to higher layers if it does.

The lasagna structure of gconf makes it quite annoying to hack on
since if you change something you often have to propagate it through
all these damn layers, but then again, each layer does do something
and so it's hard to get rid of them.
 
> And in any case GConf will complain that there's no writable database
> every time on load, since the ACAP backend wouldn't be *all*
> writable.

We should probably kill that warning, but another thing that needs
doing along with that is to make it not an error to set a key and fail
due to it being locked down. i.e. silently drop writes to a locked
down key. I haven't done this since I can't decide if it's
backward-incompatible.

Havoc