Image 01
profile-image

espinosa707

Jan Uhlir
beagle KIO slave

Various KDE 1.-4. Improvements by dbera 25 comments

Yes, you are right. "protocol" name should change to something like "search:/" as someone suggested. Try to bother author.

But indeed it's not matter of the name. Beagle as a project is much better known.
It's really slightly more older a propably mature but kio_clucene is utterly uknown. - Sep 01 2005
beagle KIO slave

Various KDE 1.-4. Improvements by dbera 25 comments

Beagle and Kio_lucene really USE THE SAME SEARCH ENGINE!!! Lucene!

Lucene it a mature Java project with a port to C++ and Mono, they are like one-egg twins. Kio-lucene uses C++ port and Beagle uses Mono port. Guess which is quicker ;-)

See:
http://lucene.apache.org/java/docs/index.html
http://www.dotlucene.net/
http://clucene.sourceforge.net/


Beangle is a just layer above Lucene. Layer which offers:
1) integration with Gnome
2) gnome app for viewing results
3) automatic background indexing
(using kernel inotify)
4) smart recognition of already indexed
files using extended file attributes

1 and 2) we don't need in KDE. Kio_Lucene already offers this for KDE/Konqueror

3 and 4) cool features, but should be implemented in KDE/KIO using KDED service (configurable from KCenter) + KDirWatch (can use inotify, if present in kernel) for checking file changes.
This feature should stay optional, as many user, including me, prefers manual index creation (or a Cron job).

As I can see, Beagle gets much more better propagation. Kio_lucene is nearly unknown.

BTW: Beagle also depends on filesystem extended attributes. Not all filesystems support them (FAT,NTFS,..) and even ext3 in many distributions is set not to use them by default.

This is from FAQ:

Do I really need extended attributes? Isn't there a fallback in place?

Yes, this is possible using an sqlite-based fallback. However, using this as the primary store is very slow, so using extended attributes is recommended. - Aug 31 2005
Dou you thing about some cooperation with project KAT:
http://kde-apps.org/content/show.php?content=22135

I know, there are slight differences in project aims, but they have (can have) much in common!

What about create common pluggble interface for extracting texts and metainfo from documents!? Then we can use there plugins in both project, pick the best ones (place for alternatives left) and share the effort!

Is it possible? - Aug 31 2005
Dou you thing about some cooperation with project KAT:
http://kde-apps.org/content/show.php?content=22135

I know, there are slight differences in project aims, but they have (can have) much in common!

What about create common pluggble interface for extracting texts and metainfo from documents!? Then we can use there plugins in both project, pick the best ones (place for alternatives left) and share the effort!

Is it possible? - Aug 31 2005
beagle KIO slave

Various KDE 1.-4. Improvements by dbera 25 comments

Look at projects

Kio_clucene
http://kde-apps.org/content/show.php?content=23874

Kat - Desktop Search Environment
http://kde-apps.org/content/show.php?content=22135

..the functionality is already there - Aug 31 2005
beagle KIO slave

Various KDE 1.-4. Improvements by dbera 25 comments

Are you aware of kio-clucene?
http://kde-apps.org/content/show.php?content=23874

It's based on Lucene (C++ port of Lucene) the same backend like Begle. So it provides the same searching capablities. But it has
much less dependencies (no Mono, no inotify ...), the code is more mature and additional features, like saving results to virtual folders.

I can see only ONE advantage of your project, Beagle is capable of automatic indexing (based on inotify).

Would you mind to work cooperatively on one project to make it more polished, to add NEW features - like automatic indexing or share document plugins with KAT - instead of creating new competing project?

There is too much duplicated projects with the same aim (or nearly the same):
Gwenview vs. ShowImg
Kaffeine vs. KMPlayer vs. KPlayer
etc. etc. - Aug 31 2005