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.