[Tracker] Tracker Marketing - part 2

[Luca Ferretti <elle uca libero it>]

<-- part 1 is in other message on list -->

As hinted on part 1, following GStreamer framework, I think Tracker
could split itself in the the following modules:
      * tracker (or tracker-core): the core module providing the
        database, the daemon, a GLIB/GObject based library/API to query
        the database, a GLIB/GObject based library/API to define and
        register extractors, the DBUS stuff and any other stuff needed
        to build tracker-based applications and utilities
      * tracker-extractors: the current set of metadata and content
        extractors; this module of course should depend on tracker-core
        and on external stuff needed to extract metadata (exif, poppler,
        gstreamer..). Features of this module are not needed by
        ext-developers that like to build tracker-based application:
        this module is important only for end-users
      * tracker-search-tool (or tracker-tools): GTK+ widgets, the
        default GUI search tool and any other graphical/desktop stuff
        like Nautilus integration.

While this could be a pain from a maintenance point of view, I'm sure it
will be good for external developers. If someone will have to build a
tracker-compliant application that only need to query the database, for
example the Nautilus file manager or a search tool, he will depend only
on "tracker" module (no needs to depend on extractors and their external
dependencies). Extractors are important to populate the database, not to
build querying applications. Extractors are important for end-users, not
for developers.

Same for the GUI search tool and GUI widgets: they are not needed for
pure search features, they are more extensions or reference
implementation of Tracker framework. And they add unuseful dependencies
for pure searches.

## One-Man Project ##

The last point in the Tracker feature list (previous email) was about
documentation. Not only about API reference, but also about
infrastructure and architectural choices. 

Why tracker is using SQLite? What it stores in database and why? How it
works exactly? Those could be interesting point to explain to
ext-developers (as well as to GNOME release team for 2.20 inclusion), as
well as to internal developers.

In fact this could help people to work on tracker-core: by now it seems
that only jamie is able to understand, change and fix it, while other
Tracker developers are able to add some extractors and implement some
stuff in Python.

About GNOME 2.20: if GNOME developers will have to use Tracker in their
applications, Tracker community have to listen their requests, explain
how tracker works, show examples how to perform queries in applications
or build new extractors. This is a little blame about Jamie reply on bug
405381 (Missing high level, GObject oriented API to use in external
applications): Jamie, I know that you are working (hard) to do this, and
nobody expects a stable and complete API on first attempt, but 'cause
Tracker features will be used by ext-developers,  I think you can't say:
"Done. This is the GObject-oriented API to use Tracker. Start using it
in your application and include Tracker in GNOME" (exaggeration, of
course). Instead you should say: "We are going to add a GObject oriented
API to Tracker. Our ideas are this, this and this. Any
suggestions/comments/other?". This is the reason I opened that bug, not
a reminder for a missing feature, but a place do propose and discuss
plausible implementation. Of course a page on live.gnome.org is also
appreciated.

## Final Notes ##

As a said this is just a personal rant. Currently Tracker works, it's
true, but from a desktop integration point of view it seems more a toy
then a search technology. Or, in other words, more a stand alone and
monolithic application than a search framework. Tracker uses some GNOME
libraries (glib, dbus, gtk+, gstreamer), but it's not ready to be
integrated in GNOME.

So, comments? Plans? Other ideas?