Bookmarks shared among desktop environments

Dave Cridland dave at
Tue Apr 19 15:42:18 EEST 2005

On Tue Apr 19 12:33:12 2005, Jamie McCracken wrote:
> Dave Cridland wrote:
>> IMHO, if we're serious about wanting to store lightweight 
>> database-like data in D-Conf, then we really ought to consider 
>> replacing a key/value system with a key=>{collection of named 
>> attributes} system. key/value pairs are easy to implement is such 
>> a model, whereas emulating structures within a key/value model 
>> looks like a nasty hack.
> Its not really a nasty hack because the key/value stuff is really 
> only a limitation of LDAP.

I'm confused, because I thought LDAP modelled a data store as 
objects, which themselves have attributes. (I thought X.500 did, as 
well. As does SQL, ACAP, XML, and arguably even GConf). Obviously you 
can reference individual attributes, and, in a sense, object-DN + 
attribute => key, but semantically, it's an object.

I think you've missed my point anyway - it's not whether the backend 
datastore really handles things as key/value, or as objects with 

It's whether the API - and in particular the data model it 
encapsulates - should present structures or key/value.

A preference-data specific API - such as libgconf - is welcome, of 
course, to provide a "flattened" view of preferences, using only a 
single attribute of each named structure. But since most data storage 
models already provide an encapsulation of things-with-attributes, it 
seems a shame to re-implement a hack on top.

All this depends on whether we wish to provide a single, uniform, 
system which provides access to both preference data, and lightweight 
database-like data such as bookmarks.

If the consensus is that we should never attempt this, then all of 
this is moot anyway. If the consensus is that we should, eventually, 
then it's worth considering these issues now, not later.

I've done all this, so obviously I think there's real benefit to 
having arbitrary structured data, including preferences, 
addressbooks, and bookmarks, all stored and accessed via some uniform 
method which allows for roaming between sites, and sharing of data. 
Others will probably say it's too ambitious.


More information about the xdg mailing list