<snip>
ICAP is not ideal for implementing control points other than at the
beginning of messages. It would be awkward and performance-expensive to
use ICAP for quota control if you want to change things in the middle of
a transaction. ICAP also lacks proactive notifications from the ICAP
server to Squid, which would be nice for certain quota operations.
Compared to ICAP, eCAP has a much lower performance overhead, but has a
similar beginning-of-message design limitation. If you want to do this
using loadable modules, we could discuss extending eCAP, but I am not
sure it is the best approach.
I recommend considering reshaping client_db code to work with shared
memory so that it can work correctly in SMP mode. I do not think that
would be very difficult to do and it would be immediately useful.
Once that is done, you can add a control message queue and use external
processes to manage the quota database as needed. This design would
minimize performance impact while allowing for any external quote
management programs to co-exist with Squid.
HTH,
Alex.
Yip, seems to be the general feeling out there. With this redesign,
would iCAP and eCAP not move into the same "hooks" ? They might not be
external programs, but the connections to the servers can be made at
that time ?
Alex, would it be ok if I pop a few emails over to you to assist with
the SMP stuff, if needed ?
Cheers,
Pieter
