 |
 |
(in case you get confused by the change of signature: I've failed to notice sending previous posts under nick "Kuba", Jakub Skoczen is my full name) On Tue, May 18, 2010 at 8:20 PM, Jonathan Rochkind <[log in to unmask]> wrote: > 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. Well, that and the fact that the server may perform some additional, on-the-fly processing on the retrieved results - eg. de-duplication or re-ranking. Surely, partial (async) responses may not have the quality of a complete, fully processed result but at least keep the user occupied during the process. > > 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. Is there a particular "extensibility" feature in the protocol that allows for this? > > > > 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:[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