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

On Thu, 2008-02-14 at 15:57 -0700, Alex Rousskov wrote:
> On Fri, 2008-02-15 at 09:07 +1100, Robert Collins wrote:
> > On Thu, 2008-02-14 at 09:09 -0700, Alex Rousskov wrote:
> > > An eCAP loadable module needs to plug into Squid message processing
> > > pipeline, similar to how ICAP servers do that now, but without ICAP/TCP
> > > overheads. I see two design choices for giving the module efficient
> > > access to Squid:
> > >
> > > 1) Expose Squid internals: Publish/install Squid headers and
> > > libraries to give direct access to Squid resources. This
> > > approach will most likely require installing pretty much all
> > > headers because the module may need to use many Squid services
> > > (e.g., DNS lookups) and because of the dependencies between
> > > Squid headers.
> >
> > I prefer this technically because it means that work done to make eCAP
> > clean will naturally clean up squid too.
>
> I agree that a more thorough cleanup would be required to install
> headers. On the other hand, most of that cleanup effort is unrelated to
> Squid code quality as such (see the squid/src/squid/ issue for an
> example). The effort would be directed at satisfying external
> requirements placed on installable libraries and not on Squid code
> quality. In other words, this may add work that does not really benefit
> Squid directly.
>
> The amount and complexity of that extra work may even derail the
> cleanup! With option (2), that should not happen.

Exposing the full header set is really not that hard. Doing it
tastefully is harder. But thats not what I meant.

What I meant was that when an eCAP module needs (say) DNS access, there
will be someone looking at the ease of use of the DNS interface in
squid. And just that act will provide some pressure to improve things.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
>