Re: [Tracker] Upcomming API review



Samuel Cormier-Iijima wrote:
I'm not sure something like this would be a great idea, unless there
were another method of storing the bookmarks. Users often have
preferences about more than just the bookmarks themselves (order,
expanded or not). Also, this would lead to some strange problems if
(for example) the user happened to download a file with that metadata
and tracker indexed it, or if another program used the same format or
something. It seems to me that the 'Right Thing' would be more to make
Epiphany store its bookmarks in something like XML, and have Tracker
be able to extract metadata directly from the bookmark file? Possibly
not (I haven't really looked at how Epiphany stores its bookmarks, so
I may be pulling **** out of my *** :-) A good frontend to Tracker
(which I'm thinking about writing) would have an option to turn on or
off bookmark indexing, which might also be better than having Epiphany
trying to autodetect Tracker.


the xml route is inadequate for a next generation bookmark/history database. It cannot also be shared with other processes due to concurrent writes.

Tracker will provide a multi threaded interface with full concurrency for any type of object (its like EDS but more generic and powerful).

Firefox 2.0 is going to be using a DB for this so it can do fast instant searching of history. So Epiphany will want to match this.

It also means more power so you can add tagging and custom *extensible* metadata efficiently.



--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]