9 Nov
2010
9 Nov
'10
5:43 p.m.
Le 09/11/2010 18:24, Zeno Tajoli a écrit : >> * last month, we sent a mail about moving to solR. Another sponsored >> work (thanks St Etienne). Some have answered. BUT : no decision has been >> taken. I don't mean here saying "ok, BibLibre, we will integrate your >> work without looking at how you did it", but no-one has said "OK, >> BibLibre, it's where the project want to go, your arguments are fine, >> there is only one problem with z3950 server that seems to be solvable. >> If it is solved, this streategic decision is taken". We have to go >> ahead, and now, if it's not accepted by the community, our only option >> will be to fork ! > For me (and others two italian users, not here and not CILEA clients) > the answer is: > Yes, do the solr search BUT mantains Zebra option. > Using a periodical reboot, for us, the deamon zebraque is OK > And we use only latin char.* Last week, I wrote many mails on > koha-devel to announce all our It's really too hard to do : - the language we use to speak to zebra (ccl/cql) differs to the language we use with solR. - plus there are a lot of clumsy things in Search.pm that are adressed directly by solR (like facets management). - the index management we will add directly in Koha can't be done with zebra. - we were not able to deal with 2 index engines (yes, NoZebra was hoped to be an "index engine") that had exactly the same API, i'm sure it's impossible to deal with zebra+solR at the same time ! If we really would like to deal with both, the correct way to do it would be to rewrite for both solR and zebra. Keeping the zebra API&behaviour and using solR instead is just a no-no. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08