Re: junctions for gconf

[Colm Smyth <Colm Smyth ireland sun com>]

>From: Frank Siebenlist <frank@eazel.com>
>To: Havoc Pennington <hp@redhat.com>
>Cc: "gconf-list@gnome.org" <gconf-list@gnome.org>
>
>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).

Reading XML is fine if you want to create a filter stream to turn arbitrary data
into a gconf source; however it is rather more difficult to make it a 'sink' to
be able to write arbitrary data back (although there is nothing wrong with the
idea of having readonly sources). It's important to consider that a client
may wish to fetch a single key or an entire directory; a passwd source would
need to cache the whole passwd file as a DOM in order to give reasonable
performance.

I tend to agree with Havoc that the backend mechanism is sufficiently powerful
to permit unusual sources like the passwd file to be 'joined' or merged; the
hierarchical namespace is infinite and permits other sources to join at
an arbitrary directory.

Although I have stated the case for a number of extensions for GConf, I am also
very aware that one of its cornerstones is simplicity.  If we make GConf much
more complex, then we might well be better off using an existing rich API like
LDAP (for which there are already enterprise-class and low-end opensource
implementations available), or move to an API that works well with a real XML
database. I think GConf has a lot of merits, especially the ability to combine
multiple databases into a single logical view; this feature should meet
the need to join with new sources.

Colm.

>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. 
>
>-- 
>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
>
>_______________________________________________
>Gconf-list mailing list
>Gconf-list@gnome.org
>http://mail.gnome.org/mailman/listinfo/gconf-list