https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42952 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathsabypro@gmail.com --- Comment #1 from Mathieu Saby <mathsabypro@gmail.com> --- Maybe duplicate of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40700 ? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42952 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #2)

(In reply to Mathieu Saby from comment #1)

...

Maybe duplicate of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40700 ?

Possibly although I think you're misunderstanding the role of SRU with Koha in bug 40700.

I think this is maybe one possible complication. Maybe it should still be a switch, but something the library can activate from the GUI?

100%

We have 2 different SRU server implementations currently and you might not want to offer both in parallel (Zebra and Elasticsearch).

It's a bit more complex than that. The server implementations are Zebra or z3950responder.pl. (Zebra being configured through the horribly named koha-conf.xml) Now z3950responder.pl can use Zebra or Elastic as a backend. It chooses its backend based off the "SearchEngine" system preference. Note that z3950responder.pl doesn't support authentication while Zebra does support authentication.

Do OpacSuppression, Hiding of MARC fields via visibility settings, OpacHiddenItems all work with SRU?

When using Zebra, it's pure Zebra and no Koha logic, so no those are not supported. When using z3950responder.pl with a Zebra backend, the query is passed straight through to Zebra, so no those are not supported. When using z3950responder.pl with an Elasticsearch backend, the search is mediated by Koha::SearchEngine::* modules, so there are some possibilities for support, but I think they don't do them by default.

I could see these as a reason why a library might not want to make it publicly available.

100% I think we'd want to use Unix sockets (for ease of use if nothing else) and then we'd also want to make sure we're honouring Koha's OPAC business logic (e.g. OpacSuppression, Hiding of MARC fields via visibility settings, OpacHiddenItems, etc) SRU is just a protocol. We can control what we send, although we'll run into the age old problems we have with OpacHiddenItems... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42952 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- @Katrin if we had a public SRU that honoured the OPAC business logic, we could potentially also look at that being used for a next-generation for the OPAC search interface. If loading opac-search.pl was actually super fast and initiated the search, we could have a lot more control over how searches happen. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42952 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #5)

Maybe with the known limitations it would be good if we added authentication as an option to the z3950_responder?

It would be good to add authentication to the z3950_responder.pl for sure -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.