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.
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.
I like the straightforwardness of (1) but it is crude and messy.
I like the elegance of (2) but it is more work.
Currently, I favor (2) but I want to hear what others think.
Which path would you choose?
Does anybody have better ideas on how to support eCAP modules that do
ICAP-like adaptations inside Squid?
Thank you,
Alex.
