I think the advantage is simplicity for the client, the client not
having to keep track of the different connections, the server does all
that.
But I think SRU makes the right choice in avoiding that for simplicity.
I wonder if someone, like Kuba, could design an 'extended async SRU' on
top of SRU, that is very SRU like, but builds on top of it to add just
enough operations for Kuba's use case area. I think that's the right
way to approach it.
Ray Denenberg, Library of Congress wrote:
What advantage do you see in having a "concurrent operations" feature (like
Z39.50) versus opening several connections?
(Concurrent operations introduced significant complexity into Z39.50 -
including reference ids, operations, etc, and I'm not sure anyone ever
really thought it was worth it.)
--Ray
-----Original Message-----
From: Code for Libraries [mailto:[email protected]] On Behalf Of Kuba
Sent: Tuesday, May 18, 2010 12:58 PM
To: [email protected]
Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
That is quite unfortunate, as we were looking at SRU 2.0 as a possible
candidate for the front-end protocol for Index Data's pazpar2. The main
problem with federate/broadcast/meta (however you want to call it
;) searching is that the back-end databases are scattered in different
locations or simply slow in their response times and in order to provide
decent user experience you need to be able to present some results "sooner"
than others. Waiting for the slowest database to respond is usually not an
option.
On Tue, May 18, 2010 at 5:24 PM, Ray Denenberg, Library of Congress
<[email protected]> wrote:
On 18 May 2010 15:24, Ray Denenberg, Library of Congress
<[email protected]>
wrote:
There is no synchronous operation in SRU.
Sorry, meant to say "no asynchronous .....
--Ray
