Re: [Tracker] Upcomming API review

[Jamie McCracken <jamiemcc blueyonder co uk>]

Mikkel Kamstrup Erlandsen wrote:
> I did a review of the upcomming API and I generally find it really good. 
> I have a few comments/questions though... - This is not a real critique, 
> just loose ramblings :-)

Great - all constructive criticism is most welcome!

> Search interface:
>  - I must admit I don't quite grok the Query method. It looks like 
> powerful stuff, and is prolly just a documentation problem (or lack of 
> braincells on my behalf)


okay this is a combination of text and query search. You can use it for 
example in a search GUI for advanced searches when you have an existing 
search term and want to filter it down using an rdf query. Of course you 
can also use it as before without a search term.

Some new parameters include fields for listing any additonal metadata 
fields you want with the result. EG you could specify File.Format and 
File.Size here and the variant result (should be a dict structure in 
Python) would return " Service Category, Mime Type, File size" with URI 
as the key for the dict.

> Files interface:
>  - Why would developers want to create a file at a specific size?
>  - What is the advantages of creating files through tracker? To handle 
> mime-stuff?

Nope. Tracker does not create/delete files on disk - this interface is 
for telling tracker *about* files that it does not automatically crawl.

So "create" creates an entry in Tracker's DB for the file including its 
size, mime type etc (it automatically works out the correct service to 
apply to it). This is needed for telling tracker about files its not 
watching or VFS files which tracker cannot see but whose results you 
would like to see in a tracker search or to store metadata against.


> File signals:
>  - There has been a lot of wishes for recursive watches with inotify but 
> rlove has denied any patches. It does not look like Tracker can give 
> recursive watches in this API - perhaps it will be a welcome addition?

There are no watches! Tracker simply relays file change signals for any 
file change event that it itself is watching. So if Tracker is 
recursively watching your home folder then those signals will only come 
from file changes in your home folder or below.

The signals split up path and file name so you can use dbus match rules 
to only receive signals on a certain directory if you want. I dont know 
if Python's dbus interface exposes match rules though?

> Playlist interface:
>  - Perhaps this interface can be replaced by a general list of first 
> class objects? Maybe this is actually just a special form of tagging... 

Playlists are first class objects cause they will have metadata against 
them (like name, playcount, lastplay etc). They will also be smart so 
you can define an rdf query to use for creating virtual playlists (like 
say all 90's music)

Im gonna punt the playlists and Music interfaces for now because I need 
to get *live* queries working first. I expect this in Tracker +1 rather 
than next version because its been a while since my last release and Im 
aiming to finish up the work today for the next release and get it in 
cvs asap.

Im not sure whether to use a subscriber interface for live queries 
(using a dedicated P2P Dbus socket/ DbusServer) or to use the session 
bus. The latter would spam all query changes - decisions, decisions, 
decisions...

Can the Python's Dbus bindings make use of P2P dbus interfaces?


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