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

On Thu, 2008-02-14 at 09:09 -0700, Alex Rousskov wrote:
> Hello,
>
> The Squid eCAP branch already has limited support for loadable
> modules. I have also written some eCAP-specific code, but I am not
> satisfied with its design yet. This may be the last opportunity to
> change things without rewriting a lot of code so I would love to get
> your feedback and ideas.
>
> 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.

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

Rob

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