It's not that the OPES processor wants only one response, it's that it
needs to know, in advance, which reponses are coming. In fact, it may
need to cause early termination of some responses in order to manage
cache space.
Hilarie
On Thu, 10 Apr 2003 at 22:13:05 -0600 (MDT) Alex Rousskov contended:
On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote:
> I'm thinking of image conversion as an example, but anything with the
> HTTP "vary" header more generally. If the requested OPES service is
> something general, like "decrease image size", one could imagine the
> service returning several responses, like "black and white", "300x400
> depth 3", etc. Or the service "translate to local language" might
> return "french", "german", and "italian" in some places. The OPES
> processor will look at the headers on the returned am's, looking for
> something that matches the preferences of the user who caused the
> content to be converted. Although more than one might be acceptable,
> one might be best. Without knowing whether or not it's going to be
> part of the transaction, the OPES processor would have to wait until
> transaction close to send the result.
That is fine/unavoidable, I think. There are examples where pipeline
model does not (cannot) work all the way through. Any example where
the OPES processor does post-processing, and that post-processing
needs to know all adapted response(s) before starting, will break
pipeline at the OPES processor. Note that
(a) it does not break the protocol, just prevents
certain optimizations
(b) I cannot think of any optimization that is
not supported by OCP but will work better that OCP
here
(c) OPES processor may relay user preferences to
the callout server so that the serve can produce
a single best response (if the server is smart
enough to do that). This can be done via metadata,
of course.