On Thu, 2007-03-08 at 17:10 +0100, Luca Ferretti wrote: > Il giorno gio, 08/03/2007 alle 14.41 +0100, Michael Biebl ha scritto: > > 2007/3/8, Luca Ferretti <[EMAIL PROTECTED]>: > > > <-- part 1 is in other message on list --> > > > > > > > > > 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. > > Yes, but this is on package-side. The same "orthogonality" between core > features, extractors and UI/GNOME-integration should occur IMHO in > sources-side too. > > > 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) > > Something like GStreamer plugins or external command line tools like > GNOME thumbnailers, but we should test performances. Ideally you should > be able to install per-user extracts as well as disable them to prevent > data indexing. > > This is another interesting stuff to discuss. What's the better solution > for ext-developers, keeping speed and reliability? > > Example (just a plausible scenario): > I'm a GIMP developer and I want to add a metadata extractors for xcf > format: level names, resolution, color space... Let's assume that > Tracker team say: "sorry, we don't want this extractor in our package, > 'cause XCF is a format used only by GIMP-addicted artists, it's not a > well known and widespread format as PNG or JPEG." GIMP developer will > have to provide this extractor withing GIMP sources (here is why I > suggested to have few dependencies for tracker-core, only GLIB and IPC). > > The GIMP developer have to write something to extract data from XCF > files (simple text to retrieve from database for level names, special > RDF-able properties for resolution, color space...) build inside GIMP > sources if libtracker-extensions.pc is installed, install in proper > directory and enable it for all users. Once installed, trackerd daemon > have to re-scan all files managed by new extractors and index new data. > > Here are a lot of choices to make: > * the extractor format (plugin, stand binary, both) > * the location ($XDG_DATA_DIR/tracker/extractor/) and the format > of extractors (one extractor for one MIME type or one extractor > for different MIME types?) > * the framework to enable extractor, ideally something > using .desktop files (--> define custom keys) but could be > interesting provide something like .menus file to group them for > service (example: I want to disable indexing of all images) > * more and more > > Plus, of course, the API to build them, if needed.
> It's a really hard task IMHO, difficult to perform in GNOME 2.20 > timeframe. Maybe we (jamie) should start to write on live.gnome.org an > initial proposal, asking GIMP application developers :-) to review it. > Then we could branch sources and start implement. > no need - I am going to implement external services support soon which will allow any app to drop a service desktop file in a certain dir to perform extraction for a list of mime types or an entirely new service (like web feeds) these external filters can be ditributed with the client app. EG GIMP would distribute it and install it in /usr/share/tracker/services. > > > 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. > > Of course, it was just a personal scenario based on previous history. It > seems to me that Jamie is inclined to develop "in-house", then commit > new feature once completed. It's not an attack against Jamie. I'm very > tankful to Jamie for Tracker development. > > Personally I don't need any GLIB/GObject api, I'm not a GNOME developer, > I just fixed some trivial stuff here and there or suggested other, but > real GNOME developer could appreciate more clearness in development. > > To help ext-developers - and Tracker acceptance :-) - the > well-behaving-jamie should: > * write a page on live.gnome.org and/or post here in list > describing the GObject API he have in mind to implement (what > can do, what can't do, basic objects) > * open a bug on bugzilla with patches and/or a dedicated branch on > svn to test the API (when ready) > * notify both to ext-developers involved in this feature, for > comments and test in real application > > By now we don't know if Jamie is working on it (at least me), if it > works, and how it will be. This kind of communications with all > interesting details are IMHO very important for Tracker marketing. A > simple "Tracker will have it" is not so good for ext-developers. > I will update the roadmap after 0.6.0 is released > > And also gave some pointers what things are needed first. > > We could open a contest for ext-developers asking what they need (API > and feature) to make their application Tracker enabled :-) yes > > Cheers, Luca > > _______________________________________________ > tracker-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/tracker-list > _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
