Re: [Tracker] Roadmap to 0.7

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 :)

Please dont release til we have them!

Well, part of that includes writing a base class for miners to implement with things like pausing/progress/etc.

Right now we can pause the file system miner, but that's it, we get no progress updates. So I have a patch here I am working on for that.

There also a number of things missing

Metadata rank weights-should be in ontology but they are not

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.

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.

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.

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.

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.

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.

Also we should get tracker into Gnome within 6 months so clients can go
straight to tracker for metadata, tags, events etc


Please add the things you want for 0.7 to the roadmap. Remember, we can still work on features during the 0.7 branch. This is really the core essentials we are talking about. For other features that can come later we can even list those separately on that page somewhere so we can prioritise them.


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