Re: remote configuration sources

["Kenneth Lierman Jr." <kliermanm bigfoot com>]

> I think ACAP is what you want to use. Check out the RFC on ACAP.
>

I'll check it out.
 
> Had an idle-speculation conversation with Syd from the Mozilla project
> on IRC the other day, he was thinking of adding this for Mozilla.
> 
> I have some thoughts of reworking GConf so that the daemon is
> basically an ACAP server (with extensions for schemas and
> administrability), while the client-side API would remain pretty
> similar to what it is now. This would replace the custom CORBA
> protocol, and mean that e.g. Mozilla could talk to the GConf server,
> even without using the GConf client-side API. Also it would add some
> cool features such as those you mention. However, I am not going to
> have time to implement this in any interestingly-near timeframe.
>

would you even need gconfd, or could you use any generic acap daemon?

could the acap interface be implemented as a backend only?
 
> Even once you get ACAP working, I think the challenge remains to
> create a standard spec for what an address book looks like inside
> ACAP, if you want to share it among apps. Maybe this exists, I don't
> know.
> 

a quick scan through some documents makes me think the things i was
interrested in is already defined.... from
http://asg2.web.cmu.edu/acap/white-papers/acap-white-paper.html:

"Dataset types may be defined and extended as needed. The initial protocol
pre-defines a common set of dataset types: lists, mailbox lists, options,
addressbooks, media types, and bookmarks (URLs)."

> Anyhow, I think once GNOME apps are using the abstract GConf
> client-side API, then we can rearrange the backend and get a lot of
> instant benefit from doing so.
> 
> Havoc

Might we get some of the benefit in the shorter term by using gnome-vfs in
the xml backend and allow the xml files to be remoted?

Ken