Re: config system thoughts

[Elliot Lee <sopwith redhat com>]

On Thu, 22 Jul 1999, Miguel de Icaza wrote:

> 
> > You may not like the Applet_[123] approach, but terming it "a crappy hack"
> > without reason isn't exactly fair. It provides a simple, usable, and
> > accurate representation of the data in question, whereas putting all the
> > Applet_N stuff into a single data structure doesn't (the Applet_N stuff is
> > a section of the tree that the applet stores its config data in, not
> > something that the panel generates.)
> 
> It is just a hack to implement a "collection".  You have to manually
> keep track of the "N" number somewhere or you are going to fetch stale
> data.

You are going to have to keep track of the N number somewhere, whether you
call it a "collection", or whether you call it a "tree".

(Also note that iterators mean you don't normally keep track of the N
number elsewhere, as far as the panel goes. Applets don't have to keep
track of the N number - they just save & load to wherever the panel tells
them to, and this save/load is synchronous.)

> Using an XML-like API or a Lisp-like one takes care of this, then why
> should we go for the crappy and lame?

Yes, but an XML-like API would be uniform - you would use the same routine
to access any piece of the tree. My understanding was that Havoc wanted to
have a two-deep tree that we access with one set of functions, and then
the leaves of that tree would be complex data structures, which we would
have to navigate using another set of functions.

At this point of the discussion, I do not care how you actually store the
tree (we could store it all as one big data structure, two-deep tree plus
data structures, or whatever). My primary concern is that we be able to
access all leaf nodes of the tree through the same API. (I'm guessing you
would like to be able to view a piece of the tree as a GList, which is
fine, as long as the option also exists to get/set one of the list
elements directly.)

-- Elliot