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/ _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
