GNOME.org
 

Re: Proposed module: tracker

Emmanuele Bassi wrote:

hi Jamie;


Hi



correct me if I'm wrong, but it's "fast and instant" after a run of the
indexer, so is as fast as the indexer.
its an incremental indexer which only indexes files that have changed so after first run everything is fast (like google). Tracker also allows you to search while its indexing.
the indexed words are stored in an inverted word index (file based hash table) so hits can be retrieved lightning quick. 


gnome-search-tool (also) uses

locate and the locate database, so it's fast as that.  and since both
tracker and gnome-search-tool, *right now*, can search only files, the
feature set is quite similar.
Tracker, unlike locate, indexes the file contents and metadata. And unlike grep can extract text from binary files like open office, pdf and ms word.
At the moment g-s-t is only useful for filenames or text file searches whilst t-s-t is useful for all files including video/music metadata (search by artist, album etc) and image metadata as well as arbitrary tags.
So t-s-t does a lot lot more and for office workers indexing open office docs is critically important
throw in ranking (IE highest ranked results are shown first), stemming and effortless searching and it becomes a much more useful tool than g-s-t overall. 






ergo, introducing tracker-search-tool would make gnome-search-tool
obsolete.  am I wrong?


yes I am proposing replacing g-s-t with t-s-t.
we have simply taken g-s-t and plugged in tracker so we are reusing a lot of the existing g-s-t code. 




  If what's proposed for inclusion

is tracker-the-indexer, then until we have a use for the indexer in more
than one application, I'd wait for its inclusion; same goes for
tracker-the-database.
um well Nautilus and Deskbar both have tracker support. So that makes 3 apps (including t-s-t) 

nautilus and deskbar-applet dlopen tracker (and beagle) if found, so
it's not really a full support.
as gnome dependencies must be approved, gnome modules can only optionally depend on tracker (until it gets in of course) 

There is no way round that




   I'd also like to see a tracker-library to access

the data without having to implement the D-Bus calls into each and every
application.
we have a c based libtracker but most of the apps that use tracker are python based and they prefer the native dbus but apps can choose between both 

libtracker is a thin, low-level layer against d-bus; I was looking for a
more high-level library for people not using a high level language with
a native d-bus binding - or people who want to use GObject and the main
loop provided by GLib.


AFAIK, dbus-glib has the mainloop integration already.

(at least all the async calls in nautilus and t-s-t work as expected.)
The idea of Dbus is to remove the need for thick libs or explicit bindings. Some even use the raw autogenerated stuff as the lib although I decided to just hide away the dbus'isms in libtracker.
Its so simple to use that im not sure a more complex api with gobjects is needed 





I'd also like for tracker to become less of a moving target: in the past
six months tracker changed the database backend twice (at least), API,
UI; 
UI has not changed at all

its proposed for Desktop not platform so moving API should not be an issue


the fact that libraries in the desktop release *may* break the API/ABI
rules is not a "free for all" situation: even libraries in the desktop
release should limit the API/ABI breakage - especially if they plan to
be used by more than one application.
well wrt to the nauiltus code - I wrote it for the first release of tracker in January and have not had to change it so API stability has been there through umpteen releases.
I am loathe to break API and avoid it where possible. I have no plans to cause a lot of pain to potential adopters
I have only proposed it now as im confident tracker wont need any more *major* overhauls. 


and it still indexes just plain text files, images and audio files,

with all the interesting stuff (emails, contacts, im conversations,
bookmarks, etc.) marked as TODO.
emails is 95% done as of today and we should have a release for that in a week or two 

chat logs are on their way.


and are you sure that proposing tracker at this point in time is the
wisest approach?  having it into GNOME SVN and spreading its usage is
far more important than a "blessing"; since tracker is still growing
this fast it doesn't really need publicity, and it won't benefit of
being into the desktop release, as that adds constraints that surely
will soon become too tight.
well as I said above, the big problem right now is that desktop modules cannot depend on tracker unless tracker is either an approved dependency or tracker gets into the desktop.
Once in the desktop we can begin integrating it further more easily. If it does not get in then I will ask for it to be a dependency but something has to give otherwise its going to get really difficult to integrate tracker. 

I am more worried about not being able to integrate than the constraints
But as t-s-t is proposed as a replacement for g-s-t that should not matter (the latter being files based also) 

if tracker is to obsolete gnome-search-tool, then it should offer at
least more features, or be a cleaner approach; otherwise, I'm following
the most conservative path, here.


see above




Above all, anyway, I'd like to be able to *not* use "tracker" as a catch
all for indexer, database, search UI and API.

well we need something if we want to compete with Vista and OS/X.


this is not an excuse for rushing stuff out of the door before it's
ready and proven technology; before it allows me - as application
developer - to use it with the current (and future) platform
architecture; and, most of all, while it's still a moving target.  On
the contrary, having competitors should make us work in the direction
not only of more features, but in the direction of stability and
reliability.


I have seen no evidence that its not ready for a role as file indexer.
Tracker has been in development for over a year and has a low bug count, good stability and excellent performance. Its made its way into distros and has a growing community. The fedora devs did a lot of work integrating it into their desktop and got it to work with the gtk file selector 

Its in JHBuild and loads more people have used it and not complained
I have resisted the rush to add more features by making sure the foundations are solid and have always been conservative in my releases. I have had email code for some time now but have disabled it as I am not happy its ready for release (but it will soon enough). 



+++

so, my objection stands; it's a bit less strong, because all in all I
believe tracker can be a good addition to the desktop release - but not
in this cycle.


thats fair enough - I understand your concerns and they are legitimate.
Its just not clear when something is considered ready - I assume its when something is reasonably stable and works well enough (which is where tracker is at atm) and anyone can download it and see for themselves. 

--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]