One thing I'd like to see come out of the discussion is some idea of what we want from from a Search interface. One of the problems of finding shiny new solutions is that having chased after them you also import a lot of junk you then have to live with. (retrospectively we may have done that with zebra). I'm quite willing to believe that some of the perceived zebra problems are problems not with it per se but with how we handle it. When developing software it is a good method to write a test first that fails then write the functionality to pass that test. It means you have a clear target of what you are trying to achieve. We need to have a clear idea of what we want a search package to provide us and what constraints it must meet, otherwise we can't evaluate solutions (or even identify if the failure to meet these lies in the external software or in areas we can code our way out of them). Whatever we decide concerning zebra/Solr etc. I'd hope we come out with a clearer picture of what we need from them or from x.
Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) [email protected] skype: colin_campbell2 http://www.ptfs-europe.com _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
