junctions for gconf

[Frank Siebenlist <frank eazel com>]

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.

For example, if you want to represent user related data in gconf, you
could use the existing passwd file to generate on-the-fly a sub-set of
the information as an xml-tree and serve that through the standard gconf
interface to the client. 
So "/.../users/frank" could be pointing at the entry in the passwd file
with name frank. The /.../users node is the junction with a possible
list value of all the user names, the /.../users/frank is the node for a
user, while the nodes underneath like /.../users/frank/uid and
/.../users/frank/full-name have values relevant to frank's account. 

Junctions would be pre-defined in the namespace. Schemas would explain
their use and data types. Many, maybe most, will be read-only, although
you may consider even updating some config files through gconf. Each
junction could have a program/script associated with it to read the data
and to transform it to the right xml such that it fits neatly in the
tree (could be fairly simple scripts...). Update notification is
difficult - maybe polling or fam/imon could help. The schema of a
junction node could hold all necessary info for gconfd to use including
the path of the script.

The advantage would be that you would have a single namespace to find
information about the system, users, groups, existing config files,
etc., without having to migrate anything. It would free programmers from
having to learn different APIs and/or CLIs, and instead learn one
interface while looking up namespace and schemas definitions.

These junctions may be low hanging fruit to make gconf even more
useful...

-Frank.


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 ;-)


-- 
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