9 Nov
2010
9 Nov
'10
6:11 p.m.
So there is a new search engine around the block, some clients really need it. (did you mention to them the Constellio open source product ? (Solr+Nutch...) Might be a real improvement, but i haven't read the performance analysis yet, any primary sources ? Works just fine with Resources Description Access, RDF ? SKOS ? SPARQL ? ..... If your clients need Alfresco, indeed, why not forking this product instead ? Olivier Spéciel olivier.speciel@mail.mcgill.ca 514 835-7845 ________________________________________ From: koha-bounces@lists.katipo.co.nz [koha-bounces@lists.katipo.co.nz] On Behalf Of Paul Poulain [paul.poulain@biblibre.com] Sent: November 9, 2010 12:43 PM To: koha@lists.katipo.co.nz Subject: Re: [Koha] Proposal to form Koha Technical Committee 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 _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha