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

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.

> > 2) Link with an eCAP library: Implement a Squid-independent eCAP
> > library that Squid and modules will build with to get
> > "connected" to each other. This way, Squid does not have to
> > publish any of its headers (the library does). This approach may
> > simplify Squid header management and even allow integration with
> > other proxies, but it is more work because it is a stand-alone
> > library and because Squid would have to translate between
> > internal Squid types and eCAP library types.
>
> Its more work both at code and at runtime. The only thing it really
> allows that 1) doesn't is non-GPL eCAP modules.

Whether (1) requires GPL is debatable (and we should not debate that
legal question here).

(2) Is a "cleaner" solution from code quality point and module
management point of view because you are forced to carefully encapsulate
eCAP module capabilities; access to Squid internals is performed via
well-known channels. With (1), anything within Squid is up for grabs as
there are no API restrictions.

Thank you,

Alex.
Received on Thu Feb 14 2008 - 15:57:54 MST