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

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.