Report 1:
KinoSearch vs Tsearch2
The original application submitted to Google was to incorporate tsearch2 to the existing search API of Bricolage. KinoSearch seems to be another option. There has been a discussion on which of these searches would be better suited for the purpose of integrating full text search into Bricolage.
I read up on both KinoSearch and Tsearch2.
KinoSearch is currently at version 0.162
and the file format may undergo changes in the future. This might lead to a crash of the application if these changes are not taken into consideration when an upgrade happens.
Tsearch2 is compatible only with postgresql and only for versions greater than or equal 8.3.
KinoSearch is admittedly faster and has support for incremental indexing.
It can handle a large number of documents. Tsearch has limitations when it comes to handling large documents.
Tsearch uses a datatype called tsvector which represents a document, which holds a set of unique words and their positional information. But it can only hold up to 256 positions in a single document.
On the other hand KinoSearch is an adaptation of a completely Java based search engine (Lucene). I don’t know if that is really a problem, but it would be better to avoid dependencies that are uncalled for.
If implemented tsearch can provide stability. But the only hint of instability on using Kinosearch would be if the file format undergoes a change and the alpha version (which is the current KinoSearch version) is upgraded. Though this is probable, it is not something that cannot be handled; The new file format can be checked and handled when we upgrade to a higher version of Kinosearch.
Both KinoSearch and Tsearch have communities that can provide enough support. Tsearch has complete online updates and support. The online support for Kinosearch also serves our purpose. The documentation for both these project are extensive, though I found the Kinosearch to be a bit better, especially on the understandability.
KinoSearch is after all Perl based, and after an initail encounter with both tsearch and kinoseach, I am of the opinion KinoSearch might lend itself to easier integration. Also Tsearch does not provide support for mysql and depends heavily on postgresql, while Kinosearch has a core based on Java.
Kinosearch can provide more support than tsearch and requires less compromises from the users, like a mandatory upgrade of their postgresql versions. The KinoSearch API is much more tuned to customization and is more user-friendly.
Conclusion: I think we should go with KinoSearch
Perl Swirl 