(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