Re: OCP Core version head_sid4 available

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

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.