Re: [Tracker] Roadmap to 0.7

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

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


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