Reply inline:
On Tue, October 12, 2010 12:41, Thomas Krichel wrote: > > Frederic Demians writes >> >> >Just as a side note, zebra3 should be based on solr. So yet >> >another point for solr. >> >> So, isn't it the best interest of the Koha community to wait that >> Indexdata integrate Solr into Zebra? and in the meantime, switch >> Koha-Zebra interface from GRS1 to Dom in order to gain in >> granularity and customazibility. > > Yes. In any case, the zebra documentation notes that GRS1 > has been improved and replaced by DOM. > 1. WORK WHICH INDEX DATA IS DOING ALREADY. >> And as suggested by Thomas Dukleth, Koha supporters could sponsor >> directly Indexdata to speed up their work and give them a Koha >> 'direction'. Who's better than Indexdata has deep knowledge of >> search engine technlogy in Libraries arena? > > And to appear credible to them, it wouldn't be best to adopt > their recent technologies, before asking them to develop > new ones? If the Koha community would work with Index Data to support Solr/Lucene, we would not necessarily be asking Index Data to develop any new technologies which they had not already been intending to develop themselves. Index Data has added Solr/Lucene support to a several products for querying Solr/Lucene servers and integrating the result sets with Z39.50/SRU and other searches. See http://www.indexdata.com/blog/2010/09/solr-support-zoom-pazpar2-and-masterkey and http://www.indexdata.com/news/2010/10/yaz-411-available-now-solr-support . There may be some which have not yet had a public release. I did not check all the release notes. 2. WORK WHICH INDEX DATA MIGHT DO. I enquired with Index Data about the prospect of Solr/Lucene support in Zebra. Index Data has experimented with Solr/Lucene based indexing as well as other options which might be used in a next generation server for Zebra 3. A next generation version of Zebra would need some commitment of funding for development from interested parties which has apparently not been a priority from their customers most recently. However, given the work done for experimentation, the funding needed might be more modest than I would have expected otherwise. There may be other more modest options for developing support for Zebra as a Z39.50/SRU server which might be independent from Zebra as a complete indexing server if possible. What may be done with Zebra would depend upon the level of importance which the Koha community attaches to having a good Z39.50/SRU server. As I previously stated, I speculate that most libraries using Koha care very little about their own Z39.50/SRU server. Again, I will explain later the importance of Z39.50/SRU and how needing to support Z39.50/SRU for libraries is a necessity. 3. WORK FROM KNOWLEDGE INTEGRATION. I have not yet contacted Knowledge Integration to learn what is required to obtain any useful documentation for JZKit and learn whether its Z39.50/SRU feature set is as limited as it appears it may be from my examination of the source code and configuration files. 4. CLIENT VS SERVER SUPPORT FOR Z39.50/SRU. I do not think that client side support for Z39.50/SRU is enough. However, there is a potential for regression of both client and server support for Z39.50 when rewriting Search.pm without working with Index Data if they are the only company supporting the requisite software. Knowledge Integration seems to depend upon Index Data software on the client side but perhaps Knowledge Integration has some additional options to provide. I will enquire. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
