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