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 :-).

True on both counts.

So what shall this interface look like?
I was imagining an interface that pulled/set some squid data structures
for client use. Even if it was gated through an API layer.

Amos
Received on Thu Feb 14 2008 - 17:28:05 MST