Re: Proposing Tracker for inclusion into GNOME 2.18
- From: Jamie McCracken <jamiemcc blueyonder co uk>
- To: Ross Burton <ross burtonini com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Proposing Tracker for inclusion into GNOME 2.18
- Date: Tue, 24 Oct 2006 20:04:31 +0100
Ross Burton wrote:
On Mon, 2006-10-23 at 23:21 +0100, Jamie McCracken wrote:
The main reason was I didn't like the way GNOME uses loads of different,
inefficient and incompatible means of storing information (think
Berkeley DB for EDS, MBox for emails, the zillions of small performance
draining XML files used for bookmarks, history, rhythmbox's music
database and many other things). So, I wanted to bring together all this
stuff under one centralised database and in doing so increase
performance, power and memory efficiency of the platform as a whole.
I forgot to reply to this feature earlier. Does tracker have any
working support for first class objects yet? If so, how are they
stored, what is indexed, what is the API like?
Only Files at the moment. We have preliminary Email support but its not
complete yet. The Api would be specific to each object and would be
analogous to the methods on a class.
I'm curious as to how this would work for contacts, as a backend for the
EDS addressbook instead of Berkeley DB.
For each fisrt class object, the plan is to create a dedicated dbus
interface so in this case we would create a
org.freedesktop.tracker.contact interface and add various methods that
would be required (EG Get, Create, Delete etc)
For the Db, we would either reuse the Services Table or create a new one
for contacts depending on what makes a contact unique - if its a uri
then the services table would be reused. Is email address the unique
field for a contact?
Next up we would define the basic metadata or properties of the object
(EG Contact.FirstName, Contact.Surname, Contact.EmailAddress etc along
with their types) and add these to the metadata types table
the create method for the Contact interface would normally fill in the
values for the most commonly used contact metadata. Other values can be
populated using the generic metadata dbus interface. It would also
assign a unique ServiceID for the object which is used for all metadata,
keywords and links.
Thas pretty much all there is to it. We have dbus api for adding new
metadata types and for populating them so its easy to extend.
I'm working on a program now
that had added a custom field to every contact in EDS, which needs to be
indexed. Adding a custom field is no effort with the current EDS API as
it stores vCards literally, and indexing the field was achieved by
hacking the summary index code and adding the field to the summary
files. With the "first class" contact objects in tracker, can new
fields be added and indexed as required?
of course - everything but blob data is indexed (that is db indexed not
full text indexed)
Metadata is stored in a separate table according to its data type (IE
string, numeric, Date etc). We use a composite primary key (ServiceID,
MetaDataID) and the value itself is indexed.
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]