Re: OCP Core version head_sid4 available

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote:

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

Same answer, I believe. You are constructing an example where it is
impossible to avoid overheads if you assume no example-specific
negotiation of some kind.

Note, however, that it is possible to trade what you call "cache
space" for reponse time and local bandwidth: assuming reproduceable
responses, the OPES processor can send the same application message
for adaptation twice; during the first attempt, it will terminate
every adapted response after noting its metadata;  during the second
attempt, it will terminate all responses but the one(s) it preselected
after the first attempt.

Alex.

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