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.