Re: proposed architecture evolutions for GConf



Le samedi 11 novembre 2006 à 12:33 +0000, Emmanuele Bassi a écrit :
> no.
> 
> preferences API is not that simple; you end up with a lot of
> applications locking and unlocking a single file,

By no means am I talking about shipping all configuration in a single
file. The GConf tree should be mapped as a directory tree on the
filesystem - like with the current one-file-per-directory XML backend.

> you cannot have
> multiple programs changing system-wide defaults,

Erm, that's the opposite. Moving to a file-based monitoring would allow
on-the-fly changes to system-wide defaults as long as proper locking is
used. Currently this is not possible and you have to send a signal to
all running gconfd instances after changing system-wide defaults.

> and you have a lot of
> load/save code paths that might just end up blowing up you
> configuration.

I can see a risk for deadlocks, but I fail to see how you would blow the
configuration. I don't think it's impossible, of course, but I see no
obvious scenario for that.

However that could be said of the current GConf code, which can blow up
the configuration because it doesn't have proper locking (except when
global locking is enabled).

-- 
Josselin Mouette                /\./\

"Do you have any more insane proposals for me?"

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]