Re: Stage one finished

[Philip Van Hoof <spamfrommailing freax org>]

On Mon, 2005-03-07 at 17:51 +0100, Joerg Barfurth wrote:


> I guess you got that impression about the OpenOffice.org opinion from my 
> post on the xdg list. Actually I am currently rather indifferent on 
> this, as I have no real data about the trade-offs. I think for D-Conf we 
> need to reconsider this issue based on the eventual requirements and 
> maybe a little prototyping. OTOH for gconf this architectural decision 
> was made long ago. If you are aiming for a gconf-3 that might qualify to 
> become D-Conf, I would not change that unless the D-Conf discussion 
> makes this a strong design constraint.

> IOW my suggestion for a gconf-based design is to leave this as is.

If I have to rewrite most of GConf, and if there's a very strong reason
for this, I would probably let the library write to the backend and at
the same time let it throw an event on the D-BUS daemon (for key/value
change -notifications).

Thats perhaps a way to remove the necessity of a daemon.

Mind, however, that this would mean that every desktop application needs
to be aware how to write to that backend and in case the backend is, for
example, XML it would have to do locking very very well (all clients
write to the backend-files). And since being network transparant is also
a want-to-have feature, this might make such a decision harder to make.

It would basically mean that each client on each host has to connect to
that backend on the other side of the network. Rather than one daemon
connecting to one backend (per desktop host). I don't think the network-
administrators will like it when every desktop application opens a new
network connection with the configuration-backend/storage.

Unless you're going to use a VFS (like D-VFS) or rely on a tricky thing
like a network-filesystem, creating a network transparant configuration
system without a daemon running on the host where the actual
configuration data is being stored is ... well, difficult? (I don't know
how) 

-- so still you'd need to do a client-daemon architecture anyway --.


I'm convinced D-BUS is going to be network transparent some day (if not
already). But I'd rather do the connection of the daemon with the
backend network transparent (or create a network transparent backend
once it becomes a much requested feature). Without a daemon doing that
is much more difficult.

So personally I'm more pro a  "light clients versus one daemon who's
doing all the work" -architecture. 



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org