> > 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
