Re: New module proposal: tracker

On 08/11/09 20:43, Iain wrote:
Tracker 0.7 ships with a DBus API, Nepomuk as ontology, SPARQL as query
language, SPARQL UPDATE for inserting and updating data and finally
signals-per-classes as life search capability.

The DBus APIs are simple but very powerful thanks to SPARQL.

From looking at tracker again this weekend, and indeed it does work
better than the last time I checked in June (modulo some apparent big
bugs and some issues with the concept that I couldn't test due to the
bugs) but from a application developer point of view, I'm still

Essentially, I feel the APIs are far too low level and the
documentation is very very incomplete, which ended up leaving me
wandering around in dark as to what I was meant to do.

Hmm, I think the general overview is probably what is missing here. There are a lot of libraries and a lot of binaries but not a lot of explaining relationships and how it all fits together.

The Application
Development Manual is useless (I know its not finished, but its no
help at all).

Which one? :)

We currently have 2 manuals, one for the common library and one for the miner library. They need a bit more love. There are a few aspects when it comes to supporting developers.

1. Developers that want to add data miners.
2. Developers that want to use the data itself.

Both need a bit more love.

I know you guys love love love ontolgoies and SPARQL and
predicates and all that, but honestly, as an application developer I
couldn't care less.


I agree. I thought the same and that's why we have a damn ugly half good enough API in 0.6. The problem here is, everyone wants APIs which look nice and do things like give me all songs by Foo artist. But in reality, if that's almost never good enough. Often you want queries like, give me the top 5 artists and foo/bar/baz data associated with them which match "Hendr*" and order them by their hit ranking. This is a simple query. It gets more interesting in real world applications (as we have seen on the device).

The problem with APIs are, they:

- can't change
- don't change
- are too much work to be comprehensive
- aren't powerful enough
- etc, etc.

We have a lot of experience with this in 0.6.

All I want is to get at the data I want in the
easiest possible way, and looking at tracker and discovering that I
need to learn yet another language and a whole new load of boring
concepts to do that is very offputting. SPARQL, tuples, ontologies
should be internal details that you shouldn't need to know about.

Well, there are plenty of examples. There are man pages for all the commands, tracker-sparql allows you to query and experiment with your queries, tracker-search is a convenience that will list artists, albums, videos, folders, etc and search and limit and order, etc. You can see the code for that.

You can even look at tracker-search-bar and see how that works, not to dissimilar.

There is plenty of help and examples here. To provide just an API would leave you disappointed when you wanted to really use the data powerfully. In our experience on the device, this is where you end up, APIs are not good enough.

Looking at tracker/src I see 7 things begining with libtracker- and
none of them look overly helpful.

That's because 99% of them are all internal and the code base has been structured this way. Just because there is a src/libfoo doesn't mean it is for public consumption ;)

The most useful looks like
libtracker-client, but again its too low level. What I would really
like to see is some simpler high level calls that enable me to get all
data of (for example) Music, allow me to specify what fields I want,
and it should be a GObject that I can connect to signals on to find
out when a result has been added/removed/changed.

You can see how tracker-search gets music in one function call and you can also be told about added/removed/changed events too, but that's not so well documented right now. DBus signals provide these events.

We should be looking
to make our APIs as simple and easy to use as possible to enable
developers to make the applications without distracting them with
irrelevant implementation details. If this already exists, I apologise
and blame the lack of documentation.

No it doesn't exist.

But good documentation is the way to resolve this an API in libtracker-foo is not.


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