Re: [Tracker] Tracker Marketing - part 2

["Michael Biebl" <mbiebl gmail com>]

2007/3/8, 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.

This, at least to some extent, is already done by how the Debian
package is split up. So, developers/applications that don't use D-Bus
but libtrackerclient, won't have to install all Gnome dependencies,
only the libtrackerclient-dev package.
I guess, other distros can handle that similarly.

We could think about splitting the extractors (making them dlopen'able
eg.) or the like. But I'm not sure if that is a top priority at this
stage. If the architecture could be made to support such a split
(which means a loose coupling and a defined interface between the
different components inside tracker, then I'm sure all for it)

If at all, I would split t-s-t into a separate package, but we had
this discussion before. I think for now, it is okay to leave it as is.


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

documentation. You are sure correct about this one.
I can only speak for myself, that I also prefere to do more "fun"
things than writing documentation. Besides I'm often not very good at
explaining. There are people more skilled than me in that regard.

> 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

I don't understand your criticism here. Jamie didn't say, that it is
already done, but it will be.
And also gave some pointers what things are needed first.

Cheers,
Michael