Bookmarks shared among desktop environments

[Dave Cridland]

On Mon Apr 18 21:21:53 2005, Waldo Bastian wrote:
> On Monday 18 April 2005 20:39, Jamie McCracken wrote:
> > We dont need a solution to this for Dconf at this point. However I
> > suspect the keys will look something like :
> >
> > Key						Value
> > org.freedesktop.bookmarks.web.1.uri		http://www.slashdot.org
> > org.freedesktop.bookmarks.web.1.displayname	Slashdot
> > org.freedesktop.bookmarks.web.2.uri		http://linuxtoday.com
> > org.freedesktop.bookmarks.web.2.displayname	Linux Today
> >
> > org.freedesktop.bookmarks.folder.1.uri		/home/jamie/documents
> > org.freedesktop.bookmarks.folder.2.uri		/home/jamie/hacking
> 
> 
> That's something that bothers me about key based configuration 
> systems... what happens if I remove org.freedesktop.bookmarks.web.1 
> ? Do my bookmarks then start at 2? Are 1 and 2 some sort of 
> sequence numbers, or should they be seen as unique identifiers? 
> Should the config system have a function for "give me a new id that 
> isn't used yet" ? 

Yes, this is why ACAP:

a) Stores bookmarks as structures, in effect - you can delete 
individual attributes, but you "know" you're doing it. Deleting a 
bookmark involves deleting the structure.

b) Sorts bookmarks according to a case-insensitive comparison of a 
string, rather than a numeric identifier - so there's no implied 
meaning that "2" means the second bookmark.

ACAP doesn't have a "Store unique", however, which is definitely 
useful for this sort of work. (I put in an extension to handle it).

I implemented ACAP bookmarks a while ago. They work reasonably well, 
although I did extend the sorting so it wasn't sorted by the entry 
name (which is, in effect, an opaque id). I use them both for roaming 
my web bookmarks (although it's not integrated into any of the 
browsers I use), and for bookmarking other sorts of URIs, like 
interesting emails.

See 
http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-acap-book-06.txt

IIRC, Randall Gellens is thinking of updating it slightly.

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.

If we turn D-Conf into a lightweight database, then we can easily 
store bookmark data, personal addressbooks, dictionary entries, 
standardized structured email configuration, etc. In effect, we can 
handle everything ACAP was designed to do.

Dave.