Bookmarks shared among desktop environments

[Jamie McCracken]

Dave Cridland wrote:
> 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.
> 

okay I assumed the object-DN would be DConf in this case (as you might 
have non-dconf data in your LDAP account). I dunno if this is a problem?

> 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 
> attributes.
> 
> It's whether the API - and in particular the data model it encapsulates 
> - should present structures or key/value.

Clearly we would have a API for structured data that would involve 
arrays of some sort. However for the majority case where data naturally 
fits the key/value form it makes sense to have a simple API for that 
using strings (getkey/setkey). I see these types of data as being very 
different and mixing them makes the API more complex for the simple cases.


> 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.

unless its a requirement from KDE/GNOME/OOO its unlikely to be in the 
initial releases of DConf. I however would like to see it in future 
releases where we stand more chance of getting consensus if Dconf 
becomes ubiquitous. Theres no reason that it cant be bolted on 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. 

I agree

Others will probably say
> it's too ambitious.

I dont think so cause we will be using backends that support it - its 
not difficult to implement at all though getting the API right will be 
the most trickiest part.

jamie.


> 
> Dave.
> 
>