On Mon, Nov 11, 2002 at 10:01:54AM -0500, Havoc Pennington wrote: 
> No, there are several optimizations here (batch lookups, a client-side
> cache, and keeping the protocol carefully async/oneway).
> 

I should explain that more.

The main optimization that matters is that on startup an app specifies
which configuration namespace(s) it wants change notification for, and
at the same time specifies whether this namespace should be preloaded:

 gconfClient->add_dir ("/apps/gedit", GCONF_PRELOAD_RECURSIVE);

This means changes underneath /apps/gedit result in notification to
the app. But also it causes gedit to send a message "get me all the
data under /apps/gedit" and caches all that data on the client
side. There's also a way to drop the cache to save memory, but it
isn't that big for most apps and most apps don't bother to drop it.

It isn't currently implemented, but an optimization to reduce app
startup time would make the recursive preload async, so we'd only 
block for results when the app actually asked for a value:

 add_dir ("/apps/gedit")         ---- > sends async message to load
                                        all values

 (app does other initialization here)

 get_value ("/apps/gedit/foo")  <---- blocks for preload results

Anyhow, I think this covers the only case where roundtrips matter, it
keeps you from doing a huge number of roundtrips when the app
initially loads its settings. Later on if you don't drop the cache the
app still won't do roundtrips, but later on it probably doesn't matter
anyway.

For the default GConf database format, it turns out that XML parsing
is a lot of the overhead, more so than the unix domain socket. So the
server is actually a win overall when you have shared settings such as
/desktop/gnome/interface/toolbars_are_detachable, since it parses the
config files only once for the whole desktop.

Of course GConf is storage-backend-neutral, so if you wanted to kill
off the XML overhead you could use a highly optimized binary database
instead of XML files (with an obvious tradeoff where you lose
robustness) or you could use a more efficient text format.

Havoc