Re: configure options for loadable Squid modules

On Sat, 2007-10-13 at 18:33 +1300, Amos Jeffries wrote:

> I think you are both looking at this in isolation. It is not an
> all-or-nothing situation.

> squid has these types of modules:
> 1) built by default AND enabled and working by default (HTTP, ICP, etc)
> 2) built by default AND disabled by default (SNMP, etc)
> 3) require ./configure AND enabling in squid.conf

I am only concerned with the new loadable third-party modules for now.
My email and question were specific to those modules. Items 1-3 above
are not loadable modules today (and are not new). When/if they become
loadable modules, we will discuss how best to enable and configure them,
including defaults.

> 4) future third-party modules
>
> - would always be loaded dynamically.

Why always? When I build a Squid appliance or distribute Squid to my
servers, I may want to have a single Squid executable, including all the
loadable third-party modules. I will build such an executable by linking
the third-party modules with the Squid library (or libraries). Libtool
supports preloaded modules (because they address a real practical need).

> This whole discussion lends itself to provide a good name for Adrians
> earlier requested new directory 'modules'. As all the new modulised code
> with good copyright tracks gets made into modules it goes in there.

I am not against a "modules" directory for Squid extensions. A
sample/dummy eCAP adapter may reside there, for example.

We can discuss whether ICP, SNMP, or ICAP is an extension, should become
one, or is something more than that. If we do, I hope I will be able to
demonstrate the essential difference between a specific eCAP adapter
module (an extension) and an ICAP client (a built-in component). Let's
discuss that elsewhere though: This thread is about third party loadable
extension modules and not about modularizing Squid in general.

BTW, I am against the "new code" directory (regardless of the name)
because it does not reflect any technical aspect of Squid. There are
means of solving non-technical problems that do not involve moving code
around.

> Makes it clear its the modulised code and sticks with the naming
> scheme started with /helpers/ and /tools/ and /tests/

Again, I meant to ask about configure options to support new loadable
third-party modules (eCAP adapters specifically). I will re-post
available options in a separate email.

Thank you,

Alex.
Received on Sat Oct 13 2007 - 19:32:01 MDT