> And a lot of people we don't know about, I suspect, who have 
> very strong political reasons to use SOAP.  I think that 
> casting aside SOAP at this stage would be very premature, but 
> allowing an optional POST SRU at the same end point for those 
> who can and wish to support it wouldn't be a big problem.  If 
> you can switch on the input between SOAP and posted form, 
> then great. Otherwise decide which your users are more likely to need.

I'm a little worried about how we are overloading this single endpoint
(especially in the case of Yaz doing inspection to work out whether
protocol is http or z39.50, which admittedly is "clever").

The design pattern emerging in other webservices is to have a discovery
endpoint, which gives the URL endpoints for the services.

So if adopted in SRU/W, we would publish the Explain endpoint, and that
would give us whether we supported SRU (and its endpoint), SRW (and its
endpoint), Update (and its endpoint), etc...

If we are going to introduce SRU POST, I think I would suggest we do
this (although I would anticipate SRU GET and POST being always on the
same endpoint). It is backwards compatible with the current situation in
that all of these endpoints could be the same (if you want to do clever
inspection of the incoming data to workout how to handle it), but would
allow multiple endpoints for those who might regard having to do this
inspection as an unexceptable overhead.

A side effect, is that this allows elementary load balancing.

Matthew