> 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
> So the amount of code changes to the client would be relatively
Only if you built your SRU client, from the beginning, using
technology that most potential implementors would consider ludicrously
> 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
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