[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xdg
Subject: Re: Bookmarks shared among desktop environments
From: Dave Cridland <dave () cridland ! net>
Date: 2005-04-19 8:57:47
Message-ID: 20050419085747.32292.59175.polymer () peirce ! gestalt ! entity ! net
[Download RAW message or body]
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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic