Re: [Tracker] A simplified tracker idea

[Martyn Russell <martyn lanedo com>]

On 01/01/10 15:41, Yuan Yijun wrote:
> Hi,
>
> I wrote this page
> http://fedoraproject.org/wiki/User:Bbbush/Collaborative_Tracker_API to
> describe my understanding to a tracker like system, but I don't know
> whether it could be implemented. Would you please review it? Many
> thanks!

Hi,

I hope you don't mind, but I have posted this to the Tracker mailing 
list for others to see and comment on.

OK, so I have a few questions:

- Why don't you like tracker?
- I don't know how Windows search 4.0 works, how does it work?
- Your idea is to have a collaborative tracker library used by 
applications right?

Just going through your points:

--> Suggest paths that an application should or may want to monitor, 
based on the application's category and similar applications.

<-- We currently do this. The locations are configurable. But we don't 
do it based on an application. It is up to applications to push us their 
data. We do have an API for applications that want to write their own 
data miners for Tracker. It doesn't always make sense to just watch 
files change, if they have specific schemas (like a database does) which 
can change then it makes more sense to have applications push data to us 
in its raw sense than having us try to keep up with the latest schema 
changes by application X (we have done this with Evolution and it is nasty).

--> Keep a setting of those paths that an application want to monitor, 
allow applications to add/remove paths at any time.

We do this in $HOME/.config/tracker-miner-fs.cfg right now. It is not 
per application, but then I don't know if that's really necessary.

<-- Index files in those paths using general text indexing and specific 
method such as music's metadata.

--> We definitely do this already.

<-- Monitor folder/file changes in the paths, update index if necessary.

--> We definitely do this already.

<-- Notify applications about changes or status.

--> We do this too. If the ontology describes the property that got 
updated as being notifiable then we notify it over D-Bus.

<-- Cache or index file format should not be fragile, be compatible in 
releases, so user don't need to clear cache manually.

--> We are currently working on a binary-log to remedy this.

<-- No standalone process. It is started with application and quit with 
it too. So index is updated when user actually need the data, and user 
can wait. Nowadays computers are fast enough if indexing criteria were 
clear (and an initial indexing have been done.)

--> In practice this is completely flawed. What happens if application A 
writes data in a complete fashion and application B is then fired up to 
do something with the same data and doesn't use the same *complete* 
methods to update the data? It then causes all sorts of problems. 
Another example is, what if you use a terminal or some application which 
doesn't support Tracker's collaborative library - then you know nothing 
about that content. This is unacceptable.

<-- No standalone setting UI. Each application must provide such setting 
UI, to update paths. (Why provide such "index file size" or "index only 
when idle" options, if your application will rely on the index to work?)

--> That sounds like a lot of duplication and generally there would be a 
lot of overlap which is not needed.

> I found your name on tracker's mailing list. Since you wrote the
> document of one library [1], I believe you can understand what I
> intended to say.. However I don't have experience on tracker (or GNOME
> or free software development), so sorry if I did anything wrong. Best
> regards.
>
> [1] http://mail.gnome.org/archives/tracker-list/2009-December/msg00004.html

Can I suggest you look into the documentation to see how Tracker works 
in more detail here:

  http://live.gnome.org/Tracker/Documentation

--
Regards,
Martyn