Re: [Tracker] Roadmap to 0.7

On 10/07/09 13:18, Jamie McCracken wrote:
On Fri, 2009-07-10 at 12:54 +0100, Martyn Russell wrote:
well the new language would be for new features as well as replacing old
ones. Like you said we want more power to be exposed however that will
take time. I also want to widgetise everything so we can reuse them in
other tools like a tracker powered file manager

To be honest, the current UI is:

- Broken
- Badly written
- Irrelevant

In the current context of 0.7. Rewriting it would be hugely more efficient use of time here. Integrating new and old will just waste more time in my opinion.

Plus, if you look at tracker-explorer, you can see how easy it is to knock up a UI quickly using a higher level language like Vala.

Just a quick question, I suppose I could look this up anyway :) but
doesn't the FTS module use the old ontologies? It occurred to me the
other day that it could be the same unless Jurg has updated it.

I wrote the fts rank funtion but it needs to be use the correct metadata
weight and be exposed by spqarql so I can order results by rank
Right, sounds like the same point I make above.

well the rank function when I wrote it just  used weight = 1 with a
comment to use metadata weight once we knew where it would come from.
Juerg needs to update that and expose that function in sparql

the rank function simply sums (weight * number of occurences) as fts
stores the positions and hence we known number of occurrences in the

for search tool I also need FTS snippets function to  be exposed by
sparql (its in fts and I modded it to be efficient)
Well, we should be able to do this now already, I mean, if you look at
the newly added tracker-sparql man pages :) then you can see some
examples there. Also tracker-search uses FTS so you should probably look
at that too.

I dont see it there nor is it in tracker-sparql-query.vala

What branch are you using, we are now on master!

we need fts:rank and fts:snippet to be exposed by sparql query. This is
one for Juerg to do

Jurg, any comment to add here?

Well zeitgeist is potentially going to be good for us to show off
Tracker and so we should accommodate them where possible of course.

yes but we dont want it to suck due to results being relayed via dbus
from tracker-store to zeitgeit to gnome apps. That would make tracker
look much slower than it is?

Well, people can see for themselves that tracker is fast or slow, using another app on top of that really is another issue and we shouldn't be worried about this. We have had the same problems on the Maemo platform this year and we (the tracker team) have had to assist applications to make them faster and more efficient with queries. I expect we could/would do the same with the zeitgeist guys.

Common sense says its better and faster to let gnome apps get stuff from
tracker directly

Well, I don't know enough about what they plan to do here of course but actually, we do need higher level APIs and higher level libraries to make things easier for some applications on the desktop. I don't think dbus is that slow anyway and on the Maemo platform we do this effectively anyway with MAFW proxying Tracker. I don't see it as a problem.


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