Re: New module proposal: tracker

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2009-08-18 at 23:33 +0200, Sebastian Pölsterl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Philip Van Hoof schrieb:
> > On Tue, 2009-08-18 at 21:43 +0200, Maciej Piechotka wrote:
> >> On Tue, 2009-08-18 at 15:12 -0400, Jamie McCracken wrote:
> >>> On Tue, 2009-08-18 at 20:57 +0200, Lennart Poettering wrote:
> >>>
> >>> Epiphany does not share its metadata with anyone else nor can you cross
> >>> query it
> >>>
> >> I believe that gnome do and/or deskbar do it quite well w/out tracker. 
> > 
> > Let's ask the GNOME Do and Deskbar people about this? Would a system
> > like Tracker help the projects?
> > 
> Sure, parsing the epiphany bookmarks file over and over again is not a
> good solution, but it does the job. Users usually don't care *how*
> something appears on their screen as long as it actually does.

So you're saying that a system like Tracker would indeed help a project
like GNOME DO and Deskbar?

ok.

> Depending on tracker only to retrieve epiphany bookmarks in a more sane
> way is not going to happen.

That's of course not going to be Tracker's only purpose.

> The tracker store may be more useful to deskbar if more applications
> would actually use it (e.g. evolution, f-spot, rhythmbox, banshee). But
> as I see it, the ideas of tracker may be great, but far to less
> applications use it so it could be worthwhile implementing tracker-store
> support.

ok,

The fact that applications don't yet use it is a chicken and egg problem
on all counts:

The Tracker team members have been too busy working on Tracker's own
problems to focus on other applications. Besides, Tracker was not ready
API and feature-wise either.

Although we did squeeze into our personal TODO lists writing a EPlugin
for Evolution that pushes E-mail data into us, and the same for KMail
(because yeah, we try to take into account the K desktop too), for
example.

Application maintainers ain't going to just-like-that start accepting
patches that will drastically change their data models to use Tracker as
storage backend. Not unless they are sure that the way we'd change it is
also the way forward for, for example, GNOME.

So sure there are a lot of ramblings about us having to adapt all of
GNOME's desktop to start using it, but I bet that even if we'd start
making patches we'd still get as reply from many of the maintainers of
the individual applications: "sorry, but we can't depend on Tracker".

And they can't depend on Tracker, because Tracker can't go into GNOME.
And it can't go into GNOME, because applications ain't using it yet.

That's a recursive chicken and egg ;-)

Nonetheless, you'll start seeing such patches happening anyhow.

> Another problem non of the desktop search engines could solve for me is,
> to provide a way to find out how one result/item can be opened.

We have a schema (an ontology, but I'm truly and extremely shockingly
deeply frightened to use this word, as apparently people claim it to be
a buzzword) for software. You can already in Tracker say which mimeTypes
are connected to which softwares. 

So you can in fact already make the query "with which software do I open
this resource". I'm not going to type it here because that would just
inspire more buzzwordfobists. But join #tracker and I'll show you.

You can of course also just keep a table of these, yourself.

> For deskbar that's a crucial point. It doesn't help at all if I can ask
> tracker to search for xyz, but don't know how to handle the results.

Sure, ok. This is a trivial problem to solve and can already be done ^.

> To solve this dilemma we currently hard coded the commands to open specific
> types of results in the beagle module (don't know about the tracker
> module, it isn't officially part of deskbar anyway). I'd love to get rid
> of such hacks.

Okay, that's fair. Let us know how you need this, what you need and how
we can help your application with this.

> So unless you provide patches/plugins for more applications to fill
> tracker-store and even more importantly patches for applications that
> consume this data, it's -1 from me.

That's again the chicken-and-egg problem. And again will you nonetheless
see these patches happening.

But this is a process that takes long. Even if we'd have the patches for
ALL applications ready by *next minute*, then still it'll take months
for the maintainers of those applications to make up their minds about
it. And after that months to rework the patch, as upstream will have
massively changed and the patch wont apply anymore. Etc.


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be