alex at gossamer-threads
May 19, 2008, 12:41 PM
Post #21 of 25
> Anyway, I think that my opinion here is clear. What's your
> recommendation? What do the rest of yous guys think?
Personally I'd like to see Solr:
* database independent
* scalable -- if search index needs to be moved off to a separate server,
it can be done so easily, whereas it's more difficult separating
bricolage and kinosearch and its associated index.
* powerful -- very flexible search options, very quick, and good quality
* can integrate with public site -- adding a search option has been a
popular requests for the bricolage sites we are running, and solutions
like htdig, swish-e, and others don't come close to what you could do
with solr and having all the meta data available.
* fairly easy to setup -- if you have java installed (most o/s have
packages for this), download tomcat, add solar.war, minor adjust to the
config and you are set. We could help with docs here as we've done this
extensively, and have a plugin for our own forum software with setup +
* could be separate similar to the wyswyg editors, just plug in the url
to your solr instance, and you activate it.
* bigger user community around it to continue develop and enhance
We've built a plugin using Solr for our forum software, so if you need
any help/assistance for how to setup/use, please feel free to ask.
My concerns with tsearch is that it ties you into postgres, as well as
the quality of results. Since MySQL support (and windows?) might bring a
lot of new users into this, should try and keep features supported on
My concern with Kinosearch is stability. Again, we've used it
extensively and have run into a few bugs with it. Also, it is still
considered alpha quality. From the docs:
KinoSearch is officially "alpha" software, mostly because the file
format may be changed in the future. If you have an incremental indexing
app set up when that change arrives, and your sysadmin upgrades
KinoSearch unaware of that, your app will suddenly start crashing. Until
the file format issue is settled, changes to the API are also fair game.
so including this could break sites going forward as new versions are
If you don't go this way, it might be good to make the search
mechanisms hookable, so alternate ones could be used. i.e. either the
indexer/searcher are subclassable, or pluggable.
Just my 0.02 =)
Alex Krohn <alex [at] gossamer-threads>