Print

Print


Dr Robert Sanderson wrote:
> 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
> reasons:
>
> * Most communities will decide internally on a profile of usage for the
> protocol.  That profile will determine at the very least SRU vs SRW.

Profiling the way to get hold of Explain and the transport is not my cup
of tea.

> * 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
> communities.
>
> Therefore, most client developers will develop clients for the needs of
> their community.  Their community wil have already established one or more
> of SRU, SRU/POST and SRW.
>
> 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.
Sure.
>
> * Simple cross-community clients will only use SRU.
> * Such clients thus have no need to poll.
That's the way things are moving to. Before when all servers implemented
  Both SRW  and SRU there was a clear choice for developers. Not any more.

>
> * 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.
It is more much complicated that a client will have to support all the
transports out there.

> 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.
We have effectlive moved all the transport logic to clients.

We have moved the extra work to profiling ... They will have to mandate
one transport.


>>>> 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.
Well, so far clinets could be braindead. All servers supported SRU. But
if some servers say only support SRW, those braindead clients will not
work. Similarly when using some SOAP "only" toolkit, it is a problem to
work with SRU. (For example gSOAP does not do SRU).
>
>
>>>>> 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.
>
>
>
> Right, that's what I said.  :)
Good.
>
>
>> 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 :)
Those 5% tend to take most of the time. It's a great burden for client
tools that they have to support all transports out there.

I for one will have to do more work on ZOOM for YAZ. We will need an
extra option : protocol that specifies whehter the servers supports SRW,
SRU+GET, SRU+GET.. Just like in the old SR/Z39.50 days..

>>> 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.
At least there supports then supports both. That gives client developers
some freedom.
>
> "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.
It certainly will be impossible given a URL as a start. Now, well need
   URL + PROTOCOL.

> 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.
If that's a registry is not  maintained manually, _that_ will have to
poll...
queries > 1024 characters?
>>
>> So are we discussing SRU POST for no gain?
>
>
> I'd like someone to demonstrate the requirement.
Makes sense.
> 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.
True. But if getting hold of explain is difficult it doesn't help them.

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