Re: Panel's GConf usage

[Michael Meeks <michael ximian com>]

On Mon, 2003-02-24 at 22:18, Havoc Pennington wrote:
> As a total tangent - I'd generally feel that "maps" or "hashes" are a
> better model than structs, since structs seems to involve a lot of
> ABI/typesystem stuff and inevitable IDL, while "maps" could just be a
> property bag type of interface where you get fields by string
> name. "dynamic structs"?

	But such a 'dynamic struct' is just a GConf directory - surely. That's
hardly a new thing.

> > Actually, this sounds like it wouldn't be too difficult to build on top
> > of GConf, doesn't it?
> 
> If you have an ID for each item in the list, that starts to sound not
> very different from using a directory as your list and having a name
> for each subdirectory, no?

	Quite - it would be sufficient to have a GConf API that just dealt with
the mess of creating directories full of sub-directories with mangled
names, to provide the illusion of an un-ordered list. Presumably that
would mean that the change notification would scale nicely too. 

	Of course - creating an API that would handle that nicely is perhaps
tough. One could construct list model objects, with lifetime unique
integer indexes, 'removed', 'added' signals etc. GConfClient already
exposes GObject so perhaps that's not unfeasible ?

>  - However, items in a directory have no inherent ordering, while
>    items in a list do.

	For evolution, no ordering is really necessary; and were it - it'd be
easy to add an incrementing field that could be sorted on I would
imagine. The real rub, as with the panel I think is simply the mechanics
of serializing a largeish, structured, unordered list.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot