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.

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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to