> > 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.
Yes, I spotted that and came to the same conclusion.
The only issue with this technique is that you couldn't reference a
resultSetId in one of the pipeline commands which was created by an
earlier pipelined command but I don't think that there is a requirement
to pipeline sequences of this type (and this session issue is probably
why they suggest not pipelining posts?)
> That might
> be difficult to implement with some web server tools, I reckon (they
> might not
> allow pipelined POST's at all).
It wouldn't be hard to create a simple SOAP message which emulates the
same thing i.e. the SOAP request takes a sequence of
SearchRetrieveRequests the return is a sequence of
SearchRetrieveResponses (the 1st being the response for the 1st request
etc.).
(Of course at this point you might start thinking about asynchronous
responses to requests, but asynchronous SOAP services are a whole new
area, that I'd suggest leaving for at least SRW 1.2 whilst the standards
settle...)
Matthew
|