Re: junctions for gconf

[Frank Siebenlist <frank eazel com>]

Havoc Pennington wrote:
> 
> Frank Siebenlist <frank@eazel.com> writes:
> > Trying to get up to speed with the gconf features and "the state of".
> >
> > One trick that came to mind when I was browsing through the docs was the
> > concept of so-called junctions in the namespace.
> > A junction being defined as a node where a different animal than gconf
> > may be responsible for the data represented in the nodes and attributes
> > of the sub-tree underneath.
> >
> 
> I _think_ we could just have a "passwd" backend that did this. I could
> be wrong. (There may also be some enhancements to the backend
> interface that would make it work better.)

If you're able to read-in xml generated by a script through the standard
backend, and you predife the schema and check the grammar, then you have
a generic, safe extension mechanism for these junctions. (it shouldn't
be very different from reading the xml from storage).

The name space could then be easily augmented by perl-script writers
that spit the information out in conforming xml.

Whether you would use a separate gconfd per "junction", like a passwd
backend, or add this to a basic gconfd seems then a matter of taste. 


> > PS. It has been a while since I've been counting parenthesis, but it may
> > be that "cadr", as in (car (cdr pair)), is more appropriate that "cdr"
> > in gconf_value_cdr()to get to the second element of the pair as cdr
> > return the rest as a list and not as an "atom"... real lisp-heads may
> > take offense ;-)
> >
> 
> cdr is the second element in a _pair_ though, that's a pair not a
> list. i.e. (cons A B) where A and B are both atoms...
> 
> I should probably have called them first/second instead of car/cdr,
> since most people aren't lisp-heads ;-)

I stand corrected...

-Frank.

-- 
Frank Siebenlist        frank@eazel.com
The Security Guy        Eazel, Inc.
2189 Leghorn Street     Mountain View, CA 94043
Tel: +1(650)940-2029    Fax: +1(650)940-2099