Print

Print


> Date: Wed, 10 Aug 2005 21:55:23 +0100
> From: "Matthew J. Dovey" <[log in to unmask]>
>
>>> This maybe an example where ultimately SRU and SRW may have to
>>> part company - i.e. where this is real need for structure in the
>>> request.  Arguably if the requirement is complex enough to require
>>> structure in the request it is probably too complex for SRU which
>>> is intended to have a low barrier of implementation.
>>
>> I have problems with that idea.  Imagine someone who's built up an
>> SRU client, been happily using it for several years, then wants to
>> add the ability to request DC wrapped in METS.  I think it would be
>> terribly hard on that person to say that they have to start over
>> with a completely different protocol.
>
> Apart from it isn't a completely different protocol -

For someone who's built his client using a web-browser and style
sheets, or using LibWWW-Perl and and XML parser, it's a completely
different protocol.

> So the amount of code changes to the client would be relatively
> minor.

Only if you built your SRU client, from the beginning, using
technology that most potential implementors would consider ludicrously
overpowered.

> The SRU client writer already faces this - once a query becomes
> complex it risks exceeding the practical limits of the length of a
> URL (although there is no official limit, servers, browsers and
> firewalls often place limits on the length, not least of all as
> extremely large URLs are a common hackers trick in the hope of
> overloading buffers).

We know the solution to this -- SRU/POST.  That is a matter of
changing _one word_ in the client from GET to POST.  Not comparable to
the upheaval of moving from SRU to SRW.

> Likewise key/value pairs have a limit compare to richer XML
> structures.

This is an issue, sure.

> SRU is lighter weight that SRW which has both advantages and
> disadvantages - this particular case might not be a good one but
> there will be others. For instance, what about if the SRU client
> writer wants to integrate with an authentication infrastructure
> based on WS-Security?  Likewise, they may need to move to SRW.

Well, sure -- if someone wants a Web-Service version of the protocol
because they want to use Web-Service stuff with it, then they need the
Web-Service version instead of the URL version.  That is a very
different situation from someone who just wants to make a slightly
more elaborate requested-schema specification.

 _/|_    ___________________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
)_v__/\  "A win as predictable as it was unexpected" -- Ian XXX, on
         Millwall 2, Rotherham 0, 15/2/97