GNOME.org
 

Re: [Tracker] Tracker Marketing - part 2

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 <elle uca libero it>:

<-- 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
tracker-list gnome org
http://mail.gnome.org/mailman/listinfo/tracker-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]