Re: eCAP: expose Squid or link with eCAP lib?

Hi,
Alex Rousskov wrote:
>
> 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.
>

 Since the eCAP interface/library is released, it will not be easy to
make changes on it any more.
Since the eCAP interface/api is released, a number of projects will
start using this interface (this is the goal of the eCAP ). Any change
on eCAP interface will hurt these projects. This will cause problems in
the main squid development. What will happen if the correction of a
bug, requires an extra argument in an interface function?

An other example is the http headers related code/api which already
exists in squid3. All developers agree that the http parser must
rewritten which maybe requires change the HttpHeaders api too....

The second path looks safer but the decision depends on the development
time the squid developers (mainly Alex) can give.
Also maybe has a performance penalty.

Regards,
   Christos
Received on Fri Feb 15 2008 - 11:01:50 MST