Re: remote configuration sources

[Havoc Pennington <hp redhat com>]

"Kenneth Lierman Jr." <kliermanm bigfoot com> writes: 
> would you even need gconfd, or could you use any generic acap
> daemon?

I think an (interoperable) daemon with some extensions would be nice;
ACAP doesn't really address the issue of how you do administration,
for example it doesn't specify the storage backend, or let you attach
docs to a key, or handle the issue of installing defaults. (AFAIK
anyway.) ACAP is just a protocol, not an entire "config system" - so
you sort of need to define some things other than just ACAP.

> could the acap interface be implemented as a backend only?

Yes, you could just have an ACAP backend for current GConf. But I
don't know if there's a good ACAP server to use with that, and of
course it'd be a lot faster if gconfd itself was the ACAP server
instead of getting another process involved.

> 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)."

Cool.
 
> 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?

I think that'd be pretty slow/inefficient - it's probably better to
just write an "http" backend. Wouldn't be all that hard to do.
The hard part is e.g. authentication.

Havoc