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 _______________________________________________ gconf-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gconf-list
