Re: eCAP: expose Squid or link with eCAP lib?

On Fri, 2008-02-15 at 12:15 +1300, Amos Jeffries wrote:
> I imagine the basic first-signup users of eCAP will be wanting to
> perform content-filters on pages as they arrive. That only needs a
> read-only buffer of the page data and a hook to allow/deny the
> transaction.

FWIW, some of the users waiting for eCAP have full-functioning Traffic
Spicer modules that do a lot more than allow/deny based on read-only
page buffers.

I agree that it is possible to gradually cleanup and publish polished
Squid headers, but the first publication would still require a major
cleanup to remove the current inter-header dependencies! And when you
are done with that cleanup, you might as well expose pretty much
everything :-).

To do gradual exposure without the major initial cleanup, you need that
eCAP library that provides its own "clean" types and hides Squid guts
from the modules. That's pretty much the same as option #2, as nobody is
going to start with a full-blown eCAP library anyway.

I think the core question here is whether it is a good idea to expose
[polished, cleaned, improved, etc.] Squid guts? Is it better to provide
a well-defined eCAP-focused interface instead? I think an eCAP interface
is a better idea even if we have polished guts. Besides other
speculative "code quality" reasons already discussed here, I add this
one:

        Guts change. Squid3 guts will change a lot. eCAP modules should
        not stop Squid from changing, and should not suffer too much
        when Squid guts change.

I should have thought of that reason earlier, but that's why it helps to
discuss these things :-).

Thank you,

Alex.
Received on Thu Feb 14 2008 - 16:49:41 MST