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

Hi Amos,

Amos Jeffries wrote:
> 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?

Sorry, I did not mention here that I am referring to the path (1) :-)

What I am trying to say here is that giving directly access to squid
internals will add an extra problem in normal squid development
procedure, because the developers will have to think if the code
additions/changes breaks something in the squid api.

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

Yes, this is why an eCAP library will be usefull.

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

It is not a blocker using an eCAP library.
Changing the internal structures related with the http headers (eg the
HttpHeader class) does not requires to change the "http headers" api in
an ecap library.

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

The wrapper calls normally have a minimal penalty. But depending the
design of a eCAP library maybe it is required to copy/convert data
structures for use with the eCAP library. This may have performance penalty.

Regards,
   Christos

PS. I actually believe that it must exists a squid external utility
library which will be used by both squid and modules. But OK this looks
difficult right now...
Received on Sat Feb 16 2008 - 03:20:51 MST