Tsantilas Christos wrote:
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?
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.
Amos
--
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.
