 |
 |
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