2007/3/8, Luca Ferretti <[EMAIL PROTECTED]>: > <-- 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 _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
