Since we generally return results asynchronously to client systems from our MSSE (fed/meta/broadcast/aggregated/parallel/Multi-Server/Search Engine) I would just point out that we use other protocols than SRU when doing so. When we do use SRU on the client side, then we send back the results in a complete set. Otherwise we send them in tranches on a timescale controlled by the client system, usually about every 2 seconds.

Obviously an SRU-async protocol is possible, but would it be used? As a MSSE we would use it to get results from Sources, so they could be processed earlier (smaller response time) and more smoothly. But that would require Source servers implemented it, and what would their incentive be to implement it? 

For direct use with end users it would mean a browser client capable of retrieving and managing the partial data is needed. Middleware systems (between the MSSE and the user) would need to support it, and pass the benefit to the user. Any system doing heavy analysis of the results would probably not want (and may not be able) to start than analysis until all the results are obtained, because of the added messiness of handling partial results sets, from multiple Sources (it is messy - believe me). 

I would be very happy to see such a protocol (and have it implemented), and if Jakub implemented browser code to handle that end, then the users could benefit.

Peter

Peter Noerr
CTO. MuseGlobal
www.museglobal.com

> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Jakub Skoczen
> Sent: Tuesday, May 18, 2010 12:51 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current
> drafts
> 
> On Tue, May 18, 2010 at 9:17 PM, Ray Denenberg, Library of Congress
> <[log in to unmask]> wrote:
> > First, no. There are extensibility features in SRU but nothing that
> would
> > help here.
> >
> > Actually, Jonathan, what I though you were suggesting was the
> creation of a
> > (I hesitate to say it) metasearch engine. I use that term because it
> is what
> > NISO called it, when they started their metasearch initiative five or
> so
> > years ago, to create a standard for a metasearch engine, but they got
> > distracted and the effort really came to nothing.
> 
> I'm not sure if Jonathan was suggesting that but that's exactly what I
> had in mind - using SRU 2.0 as a front-end protocol for a meta-search
> engine. And yes while creating a third-party, SRU-inspired protocol
> for that purpose could work, I see very little value in such exercise.
> I suspect that, as any standard, SRU has certain limitations and, as
> an implementer, you have to work around them but you do end up with an
> obvious gain: standards compliance. SRU-inspired protocol is not quite
> the same thing, and it's probably easier to go all the way and create
> a custom, proprietary protocol.
> 
> > The premise of the metasearch engine is that there exists a single-
> thread
> > protocol, for example, SRU, and the need is to manage many threads,
> which is
> > what the metasearch engine would have done if it had ever been
> defined. This
> > is probably not an area for OASIS work, but if someone wanted to
> revive the
> > effort in NISO (and put it on the right track) it could be useful.
> >
> > --Ray
> >
> >
> > -----Original Message-----
> > From: Code for Libraries [mailto:[log in to unmask]] On Behalf
> Of
> > Jonathan Rochkind
> > Sent: Tuesday, May 18, 2010 2:56 PM
> > To: [log in to unmask]
> > Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current
> drafts
> >
> > Jakub Skoczen wrote:
> >>
> >>> 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?
> >>
> > I don't know, but that's not what I was suggesting. I was suggesting
> you
> > read the SRU spec, and then design your own "SRU-async" spec, which
> is
> > defined as "exactly like SRU 2.0, except it also has the following
> > operations, and is identified in an Explain document like X."
> >
> > Jonathan
> >
> 
> 
> 
> --
> 
> Cheers,
> Jakub