Tsantilas Christos wrote:
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?

This is not such a large problem as it seems. A published library has a version-number assigned to it is libsquidecap1.1 (for 1st release of squid ecap library)

Major changes such as entirely cutting or adding features to the API require a new version.

Minor changes such as parameters in a bug fix, only require that the old function remains for its users with some bug-compat wrapper to the new safe call (deprecated and often marked to be removed in next big release).

C++ handles overloading with different parameters natively so that is a non-issue in most cases.

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....

This is very close to being a blocker for eCAP. Unless the eCAP developer is willing to re-write v2 ecap after the Http* classes change.

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.

Wrapper calls most probably do have some penalties. With increasing delays on back-compat wrappers-on-wrappers as time (and changes) go by if they are not culled out. BUT, those penalties are born by the clients and only badly effect those who do not to maintain their programs well enough to move to the new API calls.

Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.

Reply via email to