Re: Panel's GConf usage

On Mon, 2003-02-24 at 17:18, Havoc Pennington wrote:
> 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?

Yeah, having the list implemented as a directory would probably work. 
What we need is an API that removes the complicate bits of generating
the IDs etc. from us...

> In any case it might help clarify our thinking on this topic if we
> make a list of the differences between a directory, and a
> map/hash/propertybag. Both are maps from strings (names) to values.
>  - Given transactions, multiple changes to a directory could be made
>    atomic, so there's no difference there.
>  - However, items in a directory have no inherent ordering, while
>    items in a list do. (You could also imagine changing this, 
>    gconf doesn't really *have* to follow UNIX filesystem semantics 
>    here.)

Yeah, I am not sure what the appropriate way to solve this would be. 
Maybe a special "ordering" key in the "struct"?

> It's worth thinking through how much complexity is added by allowing
> recursive datatypes. I'm not sure how bad it would be. It definitely
> makes all code dealing with GConfValue a good bit harder to write and
> verify, but conceptually isn't *that* bad.

Yeah but it would also remove the complexity from the application, which
is a good thing.  ;-)

> I don't know what implications this stuff has for LDAP etc. storage;
> Kris could maybe comment on that.

I don't either...

> The other question is how much of this you want on the
> protocol/storage level (gconf proper) and how much should be
> convenience wrapper API on the client side, or hints for gconf-editor.

I don't know the code in GConf enough to have a real opinion on this,
but it sounds to me like the backend and the protocol doesn't really
need to change much; one can just implement the nice complex data API on
top of the basic types.  That should make for a simpler implementation,
and also keep the backend code lean and clean.

Maybe there is a reason to have this at the protocol level though, I
don't know.

> In all this, I'd like to keep the general complexity level of gconf
> for both gconf maintainers and app programmers not *too* much higher
> than it currently is. If it gets much more complex I don't think we'll
> ever figure out the semantics or be able to make it stable.

Yeah, I agree on the need for simplicity, but right now it's just a
little *too* simple.  :-)

Ettore Perazzoli <ettore ximian com>

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]