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