Re: [Tracker] Upcomming API review

[Jamie McCracken <jamiemcc blueyonder co uk>]

Mikkel Kamstrup Erlandsen wrote:

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

Well it cant see or scan VFS stuff.



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

wildcards are not supported in dbus match rules unfortunately but its 
great Pyhton can do signal match rules :)


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

I see - so you mean a generic list?

I guess thats what the "project" first class object is ( a list of 
service entities).

Lists will still need to have some type to distinguish them and 
different first class objects (you want a method to get all playlists 
only and not all lists)

Will have a think about how generic lists might work. We might have 
metadata for List.Type (project, generic list, playlist whatever).

In any event, its a good idea...


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


Well if it supports match rules the signal traffic should be light 
enough to be okay (the dbus daemon routes signals so that only processes 
with the right matching rule are awoken).

P2P mode allows you to clean up when a client disconnects or crashes but 
as I will be storing live queries in a temp database table it should be 
okay anyhow (it wont cause memory leaks like Beagle which stores live 
queries results in RAM)

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