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