Ross Burton wrote: > On Tue, 2006-10-24 at 20:04 +0100, Jamie McCracken wrote: >> 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. > > Can you point to the API in the source?
The full dbus api is : http://cvs.gnome.org/viewcvs/tracker/data/tracker-introspect.xml?rev=1.12&view=markup in the source, all the dbus interfaces start with tracker-dbus-* in src/trackerd directory so files interface would be tracker-dbus-files.c > >>> 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? > > Contacts don't have a URI, and contacts have have none, one, or many > email addresses. In EDS, contacts have UIDs which are their unique > keys. okay a new table might be best then. > >> 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 > > $ grep EVC_ e-vcard.h| wc -l > 61 > > Two of those are false positives, but that means that there are > currently 59 defined keys in EDS. The version in Maemo adds another > three keys, but vCards allow arbitrary keys. Does Tracker handle this > programatically? If I add a vCard that has a number of custom fields, > can they be stored and indexed? you would need to define each metadata field individually that you want indexed if fields dont need to be indexed then they can be stored as blobs either separately or as one big blob > >>> 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. > > vCard types are quite complicated... The spec is something along the > lines of: > > FIELD;PARAM=VALUE,VALUE,...;PARAM=VALUE,VALUE;...:VALUE;VALUE;... > > i.e. > > N:Burton;Ross;;; > > N is name, a structured field. Surname, given name, title, prefix, > suffix iirc. > > X-JABBER;TYPE=WORK,PREF;X-EVOLUTION-UI-SLOT=1:[EMAIL PROTECTED] > > A Jabber account, which is the preferred entry and the work entry (TYPE > is a list of values), which appears in the first slot in the Evolution > interface (shame on Evolution for putting that in the vCard), with the > value [EMAIL PROTECTED] > > EMAIL;TYPE=INTERNET,HOME:[EMAIL PROTECTED] > > An email address for home that uses the Internet as transfer. > > Would I be able to search for all contacts that have an X-JABBER field > where TYPE contains HOME (so FOOHOMEBAR won't match)? A real-world > example from the Nokia 770: give me all contacts with an X-JABBER field > where the X-OSSO-BOUND parameter is "[EMAIL PROTECTED]". You would need to completely flatten the metadata as Contact.HomeJabberID, Contact.WorkJabberID etc so that all metadata is mapped 1:1 It would be nice as tracker is a freedesktop thingie to avoid evolution specific naming and also to make it clean and easy for other software to use. Contacts also have relevance to Emails and instant messaging so that kind of software might wanna use these contact objects too. A contact can only have one metadata value per type (this is a primary key constraint) With everything mapped 1:1 you can then use RDF query to search them > > Is all of this possible with Tracker, or can tracker not efficiently > store vCard data? I think it should be okay So basically what I would need from you is a spec for the contact object detailing what methods you need and what metadata (all flattened out although non searchable stuff can be kept as a single blob type) they need then I can look at implementing it. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
