Re: Storing of information

<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
Received on Fri Feb 17 2012 - 19:38:27 MST