Re: 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?

I'd choose (3). Some of the basic types have clean headers already.
Is it possible to incrementally grow eCAP access to the internals of
squid? Starting with, ie just a buffer of page text, and work the API up?
 I mean, we publish the available cleaned squid .h for its use starting at
lowest levels needed to support eCAP and working the way up to full
control paths. So the eCAP library never defines its own seperate types
publicly, but uses the squid ones as they get cleaned up.

I imagine the basic first-signup users of eCAP will be wanting to perform
content-filters on pages as they arrive. That only needs a read-only
buffer of the page data and a hook to allow/deny the transaction.

Amos

>
> 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 - 16:15:18 MST