 |
 |
Hi all, [Matthew]At the moment the intent is that the same URL is used for both the SRU endpoint and the SRW endpoint. [Mike](Aside: is that intent documented anywhere?) Well, the ZeeRex record contains the following info: <serverInfo protocol="SRU" version="1.1" transport="http"> <host>gondolin.hist.liv.ac.uk</host> <port>210</port> <database>IR-Explain---1</database> </serverInfo> Since serverInfo is non-repeatable (if my understanding of DTD is up-to-date) there is no way to supply more than one host/port/protocol/transport combo.. [Hedzer] What reasons are there for not allowing it, then? I'm all for [Hedzer] allowing it (mostly because of the GET length problem). [Matthew]The server has to be able to determine whether it is getting an SRU request or an SRW request, and at [Matthew]present the server can distinguish that by whether it gets a HTTP GET (hence SRU) or HTTP POST (hence [Matthew]SRW). [Matthew] Allowing a HTTP POST to be either SRW (i.e. SOAP) or an SRU based POST (or potentially a more REST like [Matthew]POST with the SearchRetrieveRequest cast in XML but not within a SOAP envelope) would [Matthew]A) require some fiddly logic at the server end which would often mean hacking the SOAP toolkits to do That's just a technicality.. [Matthew]B) potentially break existing implementations How? [Mike]But there are other ways. The YAZ implementation of SRW allows the same port to be used for both [Mike]SRW and Z39.50 -- we just peek ahead at the first few bytes of the request and switch on what we see there. [Mike]They same could certainly be done, pretty trivially, for determing whether a POST payload is SRW or SRU. I agree. Not being able to program POST content-type checking for certain implementations should not mean that the SRW/SRU protocol should forbid it. And I'm all for *not* dropping SOAP, just because not many people implement it now. Who knows how many well optimized SOAP toolkits will emerge in the future? [Mike]What we're proposing here is a really, really simple fix which doesn't seem to have any downside [Mike](theoretically at least): we let SRU client implementors change [Mike] <form method="GET"> [Mike]to [Mike] <form method="POST"> [Mike]when their URLs get too long. Hmm, that's just a simple client-side fix. But the client should be able to find out whether the server actually supports it.. I propose to extend ZeeRex: - make serverInfo repeatable - add an attribute @method to <serverInfo> like this: <serverInfo protocol="SRU" version="1.1" transport="http" method="post,get"> <host>gondolin.hist.liv.ac.uk</host> <port>80</port> <database>IR-Explain---1</database> </serverInfo> <serverInfo protocol="SRW" version="1.1" transport="http" method="post"> <host>gondolin.hist.liv.ac.uk</host> <port>8080</port> <database>IR-Explain---1</database> </serverInfo> This configures SRU on gondolin.hist.liv.ac.uk:80, POST and GET and SRW on gondolin.hist.liv.ac.uk:8080, POST <serverInfo protocol="SRW/U" version="1.1" transport="http" method="post,get"> <host>gondolin.hist.liv.ac.uk</host> <port>80</port> <database>IR-Explain---1</database> </serverInfo> This configures SRU and SRW on gondolin.hist.liv.ac.uk:80, POST and GET. (Although GET probably bites with SOAP, so maybe this is a bad example.) Question: does protocol="SRW" need extra attributes like RPC or doc/literal ?? I don't know enough about SOAP for that.. Best regards, Hedzer Westra, Systems Developer Adlib | Information Systems Reactorweg 291 3542 AD Utrecht Postbus 1436 3600 BK Maarssen tel: +31-30-241 1885 www: http://www.adlibsoft.com