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.
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?
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?
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
