 |
 |
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:[log in to unmask]] On Behalf Of Kuba Sent: Tuesday, May 18, 2010 12:58 PM To: [log in to unmask] 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 <[log in to unmask]> wrote: > On 18 May 2010 15:24, Ray Denenberg, Library of Congress > <[log in to unmask]> > wrote: >> There is no synchronous operation in SRU. > > Sorry, meant to say "no asynchronous ..... > > --Ray > -- Cheers, Jakub