Re: [Tracker] A simplified tracker idea

On 01/01/10 15:41, Yuan Yijun wrote:

I wrote this page 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


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


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]