On Sun, 19 Dec 2004, Adam Dickmeiss wrote:
> Dr Robert Sanderson wrote:

>>>  c) SRU it is. GET is mandatory. POST is optional. SRW / SOAP depricated.
>> I don't think that deprecating SRW is a good option.  There's just no
>> advantage to doing so, and see below.
> Interopability?

The minimal decrease in interoperability is more than outweighed by the
increase in implementation.

I believe that the interoperability decrease is minimal for the following

* Most communities will decide internally on a profile of usage for the
protocol.  That profile will determine at the very least SRU vs SRW.

* Most communities will have their own prefered record schemas.  This is a
technical barrier to entry for external client developers.

* There is a social barrier to entry for client developers to established

Therefore, most client developers will develop clients for the needs of
their community.  Their community wil have already established one or more

Therefore, there won't be a significant run-time requirement for polling
how to talk to the server, for most client developers.

This is compounded by:

* Any cross-community client is much more difficult to implement than an
   equivalent single community client.

* Simple cross-community clients will only use SRU.
* Such clients thus have no need to poll.

* Advanced cross-community clients by definition are more complicated.
* Such clients might wish to poll, but this is no more complicated than
   anything else that the client will have to do, including but not limited
   to automatic discovery of appropriate transformation engines for
   arbitrary record schemas.

By introducing the option, we only add a slight burden to the clients that
are already complicated to write, and the servers who wish to support it,
which are already complicated to write.

>>> The important part is that people did not implement SRW servers already,
>> Well, most of us -have-, they're just much harder to write braindead
>> clients for, and for the most part we have been interested in servers not
>> clients.
> Don't understand. Do you think, is it easer to write braindead clients
> for SRW or SRU?

Most of us have implemented SRW servers, but it's easier to write
braindead clients for SRU.  To date, no one (to my knowledge) has written
a particularly advanced client.

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

>> I don't think that's the protocol moving away from XML, or SOAP. It was
>> more a design flaw in the 1.0 spec.

>> greater than constructing the string equivalent.  It shifted the burden
>> from the server (which already has the burden of implementation) to the
>> client (which doesn't).

>> XSLT (or other tools) in a client.  There it's useful, it shifts the
>> burden of parsing the CQL first to the server, and then to the underlying
>> tools used by the client.

> For web browsers using SRU that is true. But it don't think that's true
> for servers. Constructing XML is not that hard. But as for transport I
> 100% agree .. (prefer one language, rather than two).

Right, that's what I said.  :)

> Again the focus was on web browsers implementing SRU. They have _driven_
> the spec enormously.

So far.

>>> SRU should be considered _one_ protocol. When explain is returend it
>>> should just state "I can handle POST" or "I cannot handle POST" (forgive
>> This is where I start to really disagree.
> I take that you think it's not problematic that clients will have to
> poll using the two/three request methods SRU POST, SRU GET, SOAP to
> determine the supported transport + explain for a server.

Almost correct.  I don't think that clients will have to poll, so I don't
think it's problematic because it's a non issue for 95% of clients. See
above :)

>> field today is still not very high.  Database access is, IMO, the prime
>> candidate for expansion (cf Google, Amazon) and SRW is the single real
>> contender in that field.

> Google AFAIK web service using one SOAP protocol instance. Not three.
> Same thing with Amazon.

Nope.  Amazon has the same split that we do.

"ECS follows the standard Web services model: users of the service request
data through XML over HTTP (REST) or SOAP and data is returned by the
service as an XML-formatted stream of text."

> SRW/SRU is now moving to three. And yet there is no way to "discover"
> the supported transport without polling ..

This begs the question.  You can't discover an SRW/SRU server at all.  As
soon as you know about a server, you should know how to interact with it
to get the Explain record.

Any registry will have the Explain record for the servers.  As soon
as you have the explain record, you know how to interoperate with it,
including GET vs POST.

>>> 1. Since POST does not have similar size limitations.. Update or other
>>> services will work (better).
>> Well, we do talk about this size limitiation. But has anyone actually hit
>> it in practice? Has anyone even demonstrated that current servers fail to
>> process queries > 1024 characters?
> So are we discussing SRU POST for no gain?

I'd like someone to demonstrate the requirement.

>>> 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.
>> Netcraft hasn't confirmed it yet :)

> And, it's safe to say that HTTP GET is more used than HTTP POST which
> again is more used than SOAP (per definition) .

But we're not talking about general web usage. We're talking about a web
service designed primarily for ease of use by other code, not end users
with a web browser.

> I don't see it as the SRW spec to describe all possible routes to
> information retrieval.. Just one that works well and serves 99% well ..
> and one that allows a client to configure itself when given a URL as a
> start.

I don't see how this has any relevance on SRW vs SRU/POST, unless you're
saying that people will suddenly stop implementing SRU/GET?

Getting people to correctly implement Explain in any form is much more
important than requiring a community to make a decision about which or 2
or 3 transports to support.


       ,'/:.          Dr Robert Sanderson ([log in to unmask])
   ,'--/::(@)::.      Dept. of Computer Science, Room 805
,'---/::::::::::.    University of Liverpool
____/:::::::::::::.  L5R Shop: