Sebastian Hammer wrote:
> Are there any thorny issues related to using this approach with SRW (as
> opposed to SRU, as discussed in the messages you refer to)?
The document says that in general it is only safe to pipeline GET/HEAD -
_not_ POST/PUT which means that it would only be possible to
bundle with SRU - not SRW. However, since SRW/SRU search has
exactly the same side effect that requirement could be relaxed. That might
be difficult to implement with some web server tools, I reckon (they
might not
allow pipelined POST's at all).
-- Adam
>
>
> --Sebastian
>
> At 19:56 17-09-2003 +0100, Matthew J. Dovey wrote:
>
>> We discussed this back in June and cam to a conclusion that http 1.1
>> pipelining seemed the cleanest solution (see
>> http://listserv.loc.gov/cgi-bin/wa?A2=ind0306&L=zng&F=&S=&P=3768 and
>> http://listserv.loc.gov/cgi-bin/wa?A2=ind0306&L=zng&F=&S=&P=3996)?
>>
>>
>> Matthew
>>
>> > -----Original Message-----
>> > From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]
>> > On Behalf Of Sebastian Hammer
>> > Sent: Wednesday, September 17, 2003 6:47 PM
>> > To: [log in to unmask]
>> > Subject: Agenda Item: Metasearching - Multi-database search
>> >
>> > Hi All,
>> >
>> > Ray asked Brad Buckley of Gale to provide his input on
>> > Metasearch-specific
>> > requirements. His response to Ray echoes discussion from the
>> > Metasearch
>> > workshop in Denver earlier this year and I think it's a good
>> > point to raise.
>> >
>> > Content-providers like Gale, who hosts large numbers of databases, are
>> > faced with a peculiar challenge from metasearch engines.
>> > Specifically it
>> > involves metasearchers automatically launching parallel
>> > searches against
>> > several Gale-owned databases at once. This is perceived as a
>> > useful service
>> > by the developers and operators of metasearch engines, but it creates
>> > issues related to performance for the operator of the
>> > databases. Picture a
>> > situation where a single user fires off a search in a
>> > metasearch portal
>> > which is automatically turned into 10, 20, or 100 parallel search
>> > operations against the server.. imagine this kind of activity from a
>> > popular metasearch portal, and things might start to get
>> > pretty hot in the
>> > server pit at Gale (for example).
>> >
>> > In a nutshell, the proposal is for a mechanism that allows a
>> > metasearch
>> > engine to 'bundle' these searches into a single request, and
>> > similarly to
>> > allow the server to bundle the responses into a single package.
>> >
>> > We're talking about something that goes beyond mere multi-database
>> > searching in the original Z39.50 sense of the word.. we need
>> > individual
>> > hit-counts (and result sets) back from the server, and we
>> > will probably in
>> > some cases wish to send different query expressions to different
>> > databases... it comes much more close to the idea of a
>> > compound PDU model
>> > which was discussed for Z39.50 a while back. A way to
>> > implement this would
>> > be to introduce a "wrapper" element to allow multiple SRW
>> > requests to go in
>> > the same SOAP package. Another benefit for the content
>> > provider would be
>> > the ability to manage resources by refusing individual
>> > component requests
>> > (eg. during peak loads) without having to fail all requests.
>> > Presumably
>> > this would allow greater "fairness" in managing scant resources.
>> >
>> > I am personally ambivalent about this, and even as a metasearch engine
>> > developer, I feel that there are some thorny issues here. But
>> > this is an
>> > attempt to honestly represent a requirement that was put on
>> > the table by
>> > representatives of the content providers in Denver.
>> >
>> > --Sebastian
>> > --
>> > Sebastian Hammer, Index Data <http://www.indexdata.dk/>
>> > Ph: +45 3341 0100, Fax: +45 3341 0101
>> >
>> >
>
>
> --
> Sebastian Hammer, Index Data <http://www.indexdata.dk/>
> Ph: +45 3341 0100, Fax: +45 3341 0101
>
|