GNOME.org
 

Re: Proposing Tracker for inclusion into GNOME 2.18

Joe Shaw wrote:

Hi,

I realize that my opinion probably cannot be considered objective, but I
will try my best.  I strongly feel that Tracker isn't ready to go into
GNOME in either the platform or the desktop.  Note that I'm not arguing
for Beagle here, just against Tracker.

okay, I was holding back on criticising beagle by not comparing it to 
tracker but I guess Im allowed to now... (I'll be nice dont worry!)

The reasons essentially are:

        * Tracker hasn't gotten enough widespread use.  It is not
        shipped by default on any distribution, let alone enabled.  For
        something which by its nature has to touch *all your data*, this
        is a larger negative for an indexer than, say, Tomboy or
        Deskbar.

possibly but a number of users have used it and they have not had 
anything like the problems that beagle has. We have test suites and a 
very vibrant community and mailing list where things have been very well 
tested. Touching data is read only - we are not writing anything to 
files so it wont eat your docs! (lets keep the FUD out!)



        
        * The scope of Tracker isn't clear.  Is the point to be fast

        search for files, or for all the user's data?  To what end has
        Tracker achieved its goal?

It should be clear - to be the best


        
        * If Tracker's aim is to index all of the user's personal

        information (and not just files), the indexer is far too
        immature and lacking in functionality at this point.

tracker is mature at indexing files and does a much better job than some 
leading contenders including spotlight and other commercial indexers 
which all seem to consume significant resources. Tracker is different 
and arguably better in this area.

        
        * The metadata storage APIs are not used by anything outside of

        Tracker as far as I know, and a Google Code Search turns up
        nothing.  Proposing an unused API for inclusion is a bad idea to
        me.

Not yet but I will be doing the  bookmark history stuff in Epiphany 
using this so time will tell on this. I note there is no other metadata 
server available to Gnome and its a huge missing part of the platform so 
 it should not be dismissed out of hand. Im also a database expert with 
over 10 years of designing and optimising relational databases so Im 
confident I can deliver here (especially as its a piece of cake for me!).



        
        * There doesn't appear to be any API documentation.  At least,

        none in either the libtracker/tracker.[ch] files or generated as
        part of the build process.  To give an example, there is this
        method:

        
        GPtrArray *tracker_search_query (
           TrackerClient *client, 
           int live_query_id, 
           ServiceType service, 
           char **fields, 
           const char *search_text, 
           const char *keywords, 
           const char *query,
           int offset, 
           int max_hits, 
           gboolean sort_by_service, 
           GError **error);
        
        It is hardly clear to me what fields, search_text, keywords, and

        query are or how they are different from one another.  Nor is it
        clear what type is encapsulated in the GPtrArray returned here.

this is the thin wrapper around the dbus method - see the introspect 
file for details :

http://cvs.gnome.org/viewcvs/tracker/data/tracker-introspect.xml?rev=1.12&view=markup


        
        * It's hard to tell for certain because of the above point, but

        the search APIs appear to have a major usability problem in that
        you can't search for both text and metadata at the same time
        using freeform text entered by the user.  (Think Google here,
        which searches both document content and metadata.)  This will
        be a problem when searching emails, for instance, because people
        will type "Joe Shaw eggplant" and expect it to match from the
        author field and the body of the message.

of course you can - have you tried it?


We index all indexable metadata in qdbm and its fully searchable - even 
the tags from our keyword database is searching from the fulltext index 
(they are also searchable from sqlite too in case a keyword happens to 
be a stopword)

Also rdf query allows for easy and effortless mixing of data searched 
from inverted word index  and the sqlite database so there are no limits 
here

        
        * The graphical search tool is a C application that has been

        written entirely within the last month.  This isn't long enough
        to test for stability or user experience.

Considering it uses the gnome-search-tool source which is very stable 
and I have simply removed some code and added a little here and there 
then its not as exaggerated as you make out. The application is pretty 
stable but the only way to confirm this is to try it out.

        
        * There doesn't appear to be any way to configure tracker short

        of editing a config file in ~/.Tracker.  This also means that
        emails won't be indexed by default, and if that is turned on,
        only "Inbox" and "Sent".

we only have preliminary indexing of emails which is disabled for this 
release. The next release will have it on. trackerd --help will show the 
command line options available as well.



        
While I don't want this to devolve into a Tracker vs. Beagle debate,

Beagle *is* worth mentioning because it is substantially ahead of

Tracker both in terms of functionality and maturity.  

Tracker is much more stable though from what people have told me - we 
dont hang or crash or get stuck on docs. We also dont leak much. We are 
very viable on lower end machines. Combined with our KISS approach, it 
is a fairly well designed piece of software with relatively few 
(critical) bugs.

Tracker is miles ahead on the database side (which is non-existant in 
Beagle bar your backup for systems without EA's)- we have tags/keywords, 
extensible metadata, first class object storage etc. Beagle is only 
ahead on what it indexes and heres the big point - tracker's goal is not 
to index everything under the sun but only the important stuff.


I haven't proposed

it for inclusion yet because I want it to be suitable for all GNOME
users, but I certainly don't feel that Tracker fits that criteria at
this point either.

Well Im proposing it to replace gnome-search-tool with 
tracker-search-tool and nothing you said above has any bearing on this 
(ignoring the FUD).

To sum up,


Tracker is the only desktop search that can run well on any system that 
runs Gnome (especially 256 MB machines) and therefore makes a good 
default. Desktop search is a vital part of the platform and every other 
major platform has a competent system. Allowing tracker in allows 
desktop search for everyone not just those who have the luxury of a 
modern machine.

Tracker provides a faster, lighter and stabler alternative to Beagle for 
indexing files + a whole load of other goodies thrown in for free!

It fills in vital holes in our platform (tagging,  extensible metadata 
and persistent storage)

However, as Beagle is not being proposed, cannot get into the platform ( 
C is only allowed in the platform) and is plagued by a significant no of 
problems (all of which do not apply to tracker), I dont see how 
comparing beagle to tracker is relevant to this discussion?

In any event, almost everyone who has used both have preferred tracker - 
see the ubuntu forums :

http://www.ubuntuforums.org/showthread.php?t=213844


Our mailing list is also quite busy and we have lots of  *regular* 
contributors - if tracker was not as good as I say it is then how do you 
explain that? (and no I have not marketed tracker and these guys came to 
me!)

FWIW though, if tracker and beagle can share a common dbus interface 
then letting tracker in would benefit everyone - thats the way I see it!

So if you are interested then let me know...


--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/

















[Date Prev][Date Next]   [Thread Prev][Thread Next]   
[Thread Index]
[Date Index]
[Author Index]