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. Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>. >
signature.asc
Description: This is a digitally signed message part
