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:[email protected]
Email: [email protected]
Phone: sip:[email protected]
Sales / enquiries contacts:
Email: [email protected]
Phone: +44-844-9791439 / sip:[email protected]
Support contacts:
Email: [email protected]
Phone: +44-844-4844916 / sip:[email protected]
