Dr Robert Sanderson wrote:
> On Sat, 18 Dec 2004, Adam Dickmeiss wrote:
>
>> Mike Taylor wrote:
>
>
>>> I haven't (until five minutes ago) said _anything_ about ZeeRex: just
>>> that I want the right to serve SRU requests sent via POST.  How we
>
>
>> Mike (and others) you want three web based SR protocols?
>
>
> The way that I look at it:
>
> If the choice is:
> a) Allow SRU via POST, making three possibilities for hardcore server
>    developers
> b) Not allow it, making some queries (and hence services) impossible
>    without SOAP
>
> Then I think that (a) is the better option, because the people who are
> most affected are the people who are most likely to just implement it
> anyway rather than abandoning ship.

Rob,

thank you for responding.. I pretty much agree. It will be more honest
to say.
   c) SRU it is. GET is mandatory. POST is optional. SRW / SOAP depricated.

> I suspect that what will happen is that people who would only have
> implemented SRU anyway will implement SRU and SRU/POST.  The people who
> would have implemented SRW only will still just implement SRW (but group
> is probably approaching 0).  The people who would have implemented both at
> the same endpoint will implement SRU and (both or SRW).  I think that the
> group of people who wouldn't implement SRW in favor of SRU/POST is very
> close to 0.  The question is:
>
> How much of a burden is SRU/POST to co-implement with SRW?
Don't know. The important part is that people did not implement SRW
servers already, so we're in a stage where SRU GET is the only "safe"
option.

> If that burden is large, then the landscape will probably be split into:
>
> 1) SRU + SRU/POST  (65%)
> 2) SRU + SRW       (30%)
> 3) All three       (5%)
>
> If the burden is small, then some of 2 will shuffle to 3, but it doesn't
> really affect 1, because what is putting group 1 off becoming part of
> group 2 or 3 is SRW, not SRU/POST.
>
> However we don't know the answer to that question yet.
>
>> The consequence is that clients that just works are bound to be SRU GET,
>> or try to be clever and configure (using a poll like mechaism)..
>
>
> Perhaps we should just require SRU GET?
Yep. It's the only sensible thing to do. Thinking about it, the SRW
protocol has gradually moved away from XML. XCQL gone. SOAP not being
supported by some servers (even IIRC it was required).

SRU should be considered _one_ protocol. When explain is returend it
should just state "I can handle POST" or "I cannot handle POST" (forgive
me if that's already been suggested). This will make it easy for clients
to use POST if that is desired, but do GET explain in the _first_ place.

1. Since POST does not have similar size limitations.. Update or other
services will work (better).

2. We might add a way to return documents as raw HTTP responses without
XML wrappers.. thereby adding binary transfers.. We could have a
encoding=raw or encoding=mime, maximumRecords=1 ..

We can keep SRW+SOAP . But it's going to die. If we keep it, it will be
pure marketing.. I'm certainly going to change "my" clients to use SRU
instead of SRW.

/ Adam

>
> Rob
>
>       ,'/:.          Dr Robert Sanderson ([log in to unmask])
>     ,'-/::::.        http://www.o-r-g.org/~azaroth/
>   ,'--/::(@)::.      Dept. of Computer Science, Room 805
> ,'---/::::::::::.    University of Liverpool
> ____/:::::::::::::.  L5R Shop: http://www.cardsnotwords.com/
> I L L U M I N A T I
>