Re: [Tracker] Roadmap to 0.7

[Jamie McCracken <jamie mccrack googlemail com>]

On Fri, 2009-07-10 at 12:54 +0100, Martyn Russell wrote:
> On 10/07/09 12:11, Jamie McCracken wrote:
> > I started looking at fixing the UIs yesterday so hopefully should have
> > them fixed this weekend or early nest week-I might need to bug some of
> > you for improved sparql suport
>
> Ivan, Carlos and I spoke about this yesterday. I really suggest you just 
> write the UIs from scratch. A LOT of stuff is going to changed or has 
> changed underneath you and I think it will be counter productive to use 
> the current code, especially if you want to use another language anyway :)

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


> 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
> > index
> >
> > 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

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


> Rob's tracker-explorer tool which was added to the repository this week 
> and shows off relationships based on the ontology demonstrates real time 
> searching based on user typing using the FTS work.
>
> We should really do something similar in whatever UI we deliver.

I agree
> > The above is needed by search tool so I cant finish that off until that
> > is done. No doubt there will be other issues as I fix the Uis that
> > require mods to sparql
>
> We will see :)
>
> The UIs should be simpler cleaner and faster I think this time. I can 
> help with that if you need some input.
>
> > I also think we need the Events (onto, storage and possibly dbus) to be
> > added to that list. I can add it to the file indexer to store file
> > histories during indexing once its in our onto.
>
> Not sure exactly what you mean here, but it sounds like what I mentioned 
> above with the miners all using a base class, etc and supporting a 
> similar API for an applet to just list them all and be able to control 
> them all.

Events are for things like file histories file x was edited on date d
> > I would like to eliminate the Zeitgeist daemon as what they want to do
> > is most inefficient - get relevant data from tracker to a python
> > middleware process and forward it on to clients. IOW their daemon acts
> > like a wrapper around tracker and is therefore redundant not to mention
> > bad design!!! They should use a c lib if they want to wrap tracker not a
> > python daemon!
>
> 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?

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

> As far as I could see the storage of multiple metadata per file (for 
> example) was something that might be tricky, for example, storing all 
> update timestamps for a file (for event logging). We can discuss that 
> later but I think this is something we can do after the 0.7 release.

 We can store as linked list in rdf - should not be hard

jamie