[Koha] Proposal to form Koha Technical Committee

[LAURENT Henri-Damien]

Le 19/11/2010 22:41, Thomas Dukleth a écrit :
> Reply inline:
> 
[snip]>
> Much of the capabilities which Zebra support provides are not being used
> in Koha and we are comparing our own familiarity with Zebra difficulties
> with a rosy ideal of what Solr/Lucene offers.  The first advantage of
> Solr/Lucene is that it empowers less sophisticated users to control how
> indexing is configured via a web interface.  A web interface could be
> created for Zebra but that is not an existing feature.  I am for
> everything which empowers users to more easily exercise control over their
> software.
As far as I know, solr is succesfully everyday used in many opensource
OPACS, and other projects too (thunderbird, alfresco, Drupal, .... ).
I donot claim that they are better than we do. But why should we doubt
that this solution, widely used, which is a real kind of standard in
indexing engine would be a good one ?
a) Getting and providing Suppport fot that tool would be easier. Solr
community exists.
b) Since it has been used in Vufind, and Blacklight, i think we could
share experiences more easily, Eventually direct bridges between Koha
and those solutions.


> 
> There is more than just the problem of losing very good Z39.50/SRU server
> support which would follow from BibLibre's announced implementation of
> Solr/Lucene for local indexing.  Z39.50 client support which was
> undertaken for local indexing with Zebra could enable future Z39.50/SRU
> client development without Zebra.  In rewriting searching for their own
> testing branch of Koha for Solr/Lucene implementation, BibLibre have
> removed valuable Z39.50 client support which could be used in future
> features such as querying Z39.50 servers in addition to Solr/Lucene in the
> OPAC and presenting a unified result set using Pazpar2.  Z39.50 client
> copy cataloguing support is independent from C4::Search and is thus safe
> but could not be improved using code from C4::Search if that code is gone.
It was done in koha2.2 and as far as I know, without zebra, this feature
still exists in our testing box.
It is just using direct ZOOM search rather than C4::Search::SimpleSearch.
So this valuable feature is still there. And we care not to break
existing features.
Same for the Z3950 server which we wrote a wrapper using
Net::Z3950::SimpleServer. This would allow ppl to expose their
collection as a Z3950 server.

> 
> As I have stated previously, C4::Search ought to be rewritten in future
> using prefix query format (PQF) as the native language for Z39.50. 
Well, Rewriting the whole Search With PQF would not be handy in many
aspects.  I have thought about that many times. And using PQF still
appears to me not to be the solution.
a) It is really a pain to maintain and analyse.
b) Whenever you need some more feature in your search, you have to add
some more qualifiers, and therefore provide a robust parser.
> Continuing to support Common Command Language (CCL) is trivial because Yaz
> translates CCL to PQF as it does now for Koha.  In the context of
> refactoring to support all options, future rewriting of C4::Search for
> Zebra would be rewriting it in C4::Search::Zebra along with
> C4::Search::Solr and C4::Search would become a neutral abstraction.
Again, we used Data::SearchEngine as a base for coding, and use the
results from qurying Data::SearchEngine
If anyone is willing to write a Data::SearchEngine::Zebra,
Data::SearchEngine::Nutch, Data::SearchEngine::Pazpar2, feel free to do
so. We will contribute not just to our little community. But to the
wider PERL community.

>  When
> the opportunity to rewrite the Zebra code would arise, rewriting would be
> much easier with known working code to use as a starting point, however
> imperfects.
This is why we are willing to gather use cases. To build Tests !!!
No tests have ever really been built for C4::Search.
So at the moment, I can't assign your fear of loss of features. Provide
tests and will do our best to make it pass. If it is proven that we
can't then we will talk precisely.
By the way, did you know that the "valuable" feature you told about
searching "The" was not really a zebra feature as you stated. But
provided by the Search itself. It duplicated the old need for null words
in Koha. But then again, there was no tests for that.

> 
> I have raised all of these issues on the koha-devel list without much
> specific response.  On the koha-devel list, MJ Ray has also more recently
> asked for more details about Zebra problems in a form which could be
> independently examined by others and he should have more complete replies
> than he has had thus far,
> http://lists.koha-community.org/pipermail/koha-devel/2010-November/034664.html
Well I wanted a meeting to be held and we were working on testing and
trying to assing all the raised problems in order to provide you with
more technical details. Expect another message from us soon.

-- 
Henri-Damien LAURENT
BibLibre