Re: [Tracker] Upcomming API review

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

2006/7/9, 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.

Cool. It was something along those lines I expected, but I couldn't get my head around it.
 

>
> 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.

 Ok. That makes sense then :-) However why does Tracker need to know the mime type and size? It will scan the file for indexing purposes anyway, no?

>
> 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.

Yeah, I'm with you on that. What I meant was that since Tracker watches everything in my home folder it would be possible for it to provide recursive file watching to to the apps using it. To have this service from Tracker would be valuable sine inotify doesn't provide recursive watches. I don't know, but this might duplicate functionality of Gamin (or gvfs?) - I don't know if it provides recursive watches?

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?

I never realized that dbus provided match rules :-) But a few googlings reveal that the Python bindings do support signal matching. You can do something like this:

bus.add_signal_receiver
(my_callback,
                        'Changed',
                        'org.freedesktop.Tracker.Files',
                        'org.freedesktop.Tracker',
                        '/org/freedesktop/tracker',

                        arg1='path_name')       <<<< arg0 will just be the tracker interface name
                                                <<<< arg2 matches the filename

Then you will only receive signals where the path argument is == path_name - as far as I understand. If these match rules understand wild cards, recursive watching would be achived with arg1="path_name*", but I haven't tested if this is possible.

>
> 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)

Again, is this not metadata that can be "generic-izised"? I mean a generic "playlist" could be a list of images (photo album), a list of videos, a list of odf documents (chapters in a book). Metadata for such an ObjectList could include

 - ObjectList.LastObjectAccessed
 - ObjectList.LastAccessTime
 - ObjectList.Count
etc...

Which could be used for normal playlist metadata also...

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?

I don't know. A few googlings did not reveal it either... But I would guess it did. As for my experience, the python bindings are excellent in every way. Using a dedicated bus to relay query changes sounds like the right thing though (in my limited understanding)...

Cheers,
Mikkel