eCAP: expose Squid or link with eCAP lib?

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.
Received on Thu Feb 14 2008 - 09:09:46 MST