[Koha] Technical Committee--Option to Fork -- Solr and al.

[Olivier Speciel]

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 at mail.mcgill.ca
514 835-7845
________________________________________
From: koha-bounces at lists.katipo.co.nz [koha-bounces at lists.katipo.co.nz] On Behalf Of Paul Poulain [paul.poulain at biblibre.com]
Sent: November 9, 2010 12:43 PM
To: koha at 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 at lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha