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