Re: ICAP vectoring points

On 28.11.12 16:19, Alex Rousskov wrote:

> Yes, it is both very far from trivial and, in most cases, avoidable
> by redesigning the adaptation approach itself. I have seen many use
> cases that started with a post-cache requirement, but were successfully
> massaged into avoiding one.

Can you explain this in a little more detail? The results of my ICAP
server are dependent on the user that is requesting the object, so doing
the work in respmod_precache would result in the modified object going
into the cache and then being retrieved by other users who would need
different modifications. I can't really see a way around this other
than making the objects all uncachable, which rather defeats the purpose
of having a cache. :)

At the moment I'm working around this problem by having 2 Squids - the
upstream one is running the cache and the downstream one is talking the
the ICAP server and has the cache disabled. It would be nice to be able
to remove this kludge, especially since it is causing a few issues at
the moment.

> Please make sure the new code is agnostic to the ICAP/eCAP difference,
> just like the existing adaptation code. If you find yourself accessing
> ICAP-specific code for post-cache adaptation needs, you are probably
> doing something wrong.

Thank you for the pointers - it may be many months until I get chance to
properly look into it (if at all), but at least I have a few ideas where
to begin when I have a bit of spare time.

-- 
  - Steve Hill
    Technical Director
    Opendium Limited     http://www.opendium.com
Direct contacts:
    Instant messager: xmpp:steve_at_opendium.com
    Email:            steve_at_opendium.com
    Phone:            sip:steve_at_opendium.com
Sales / enquiries contacts:
    Email:            sales_at_opendium.com
    Phone:            +44-844-9791439 / sip:sales_at_opendium.com
Support contacts:
    Email:            support_at_opendium.com
    Phone:            +44-844-4844916 / sip:support_at_opendium.com