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.
