Re: [Tracker] Roadmap to 0.7

[Martyn Russell <martyn lanedo com>]

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

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

Right.

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.

--
Regards,
Martyn