Re: New module proposal: tracker

[Martyn Russell <martyn lanedo com>]

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

--
Regards,
Martyn