[Top] [All Lists]

Re: OCP Core version head_sid4 available

2003-04-10 22:57:06

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.


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

<Prev in Thread] Current Thread [Next in Thread>