Re: cvs commit: squid3 configure.in

On mån, 2007-09-24 at 09:49 -0600, Alex Rousskov wrote: > The implications range from the "Module is a part of the GPL program > and, hence, must be GPLed!" FSF point of view to "there are no > implications except wasting time on discussing FSF FUD!" point of view. My personal view on that is tha

Re: cvs commit: squid3 configure.in

> On Wed, 2007-09-19 at 15:41 +1200, Amos Jeffries wrote: >> > On Fri, 2007-09-07 at 09:43 +0800, Adrian Chadd wrote: >> > >> > That said, doing dynamic loading has GPL implications that I'm not >> > currently comfortable with. >> > >> >> What would those be? > > The implications range from the "Mo

Re: cvs commit: squid3 configure.in

On Mon, 2007-09-24 at 09:49 -0600, Alex Rousskov wrote: > On Wed, 2007-09-19 at 15:41 +1200, Amos Jeffries wrote: > > > On Fri, 2007-09-07 at 09:43 +0800, Adrian Chadd wrote: > > > > > > That said, doing dynamic loading has GPL implications that I'm not > > > currently comfortable with. > > > > >

Re: cvs commit: squid3 configure.in

On Wed, 2007-09-19 at 15:41 +1200, Amos Jeffries wrote: > > On Fri, 2007-09-07 at 09:43 +0800, Adrian Chadd wrote: > > > > That said, doing dynamic loading has GPL implications that I'm not > > currently comfortable with. > > > > What would those be? The implications range from the "Module is a p

Re: cvs commit: squid3 configure.in

> On Fri, 2007-09-07 at 09:43 +0800, Adrian Chadd wrote: >> On Thu, Sep 06, 2007, Henrik Nordstrom wrote: >> >> > Maybe. I'll leave that to you to judge. Don't have a clear opinion >> > either way. But why not? >> > >> > HTCP and SNMP is very non-intrusive, just enabling code which is never >> > us

Re: cvs commit: squid3 configure.in

On Fri, 2007-09-07 at 09:43 +0800, Adrian Chadd wrote: > On Thu, Sep 06, 2007, Henrik Nordstrom wrote: > > > Maybe. I'll leave that to you to judge. Don't have a clear opinion > > either way. But why not? > > > > HTCP and SNMP is very non-intrusive, just enabling code which is never > > used unle

Re: cvs commit: squid3 configure.in

On lör, 2007-09-08 at 07:53 +0200, Pierangelo Masarati wrote: > I think you don't need to burn your brains too much on this point. > Figuring the perfect API out of the blue could mean spend a lot of > energies on something that would eventually freeze anyway, and if one > really needs a feature t

Re: cvs commit: squid3 configure.in

Henrik Nordstrom wrote: (snip) > a) Getting the APIs the modules needs to use to perform their actions > reasonably in shape. > > b) Adding suitable component registries, allowing modules to register at > runtime and avoiding direct knowledge of the implementation in other > parts of the code. >

Re: cvs commit: squid3 configure.in

On lör, 2007-09-08 at 08:53 +0800, Adrian Chadd wrote: > Don't suppose I could take a peek at how you did it? I'd like to write a few > things up as loadable modules - the logging stuff would be a place to start, > but I'd like to expose the whole storage API as a clean interface (even given > mos

Re: cvs commit: squid3 configure.in

On lör, 2007-09-08 at 01:48 +0300, Tsantilas Christos wrote: > I am watching closely squid at least the last 2 years and I had see > how difficult is for squid to get funds for its developments. I think it > is easier for the squid project to get money from people/companies which > creating/sel

Re: cvs commit: squid3 configure.in

On Fri, Sep 07, 2007, Alex Rousskov wrote: > > Maybe one of the goals for squid-3.1 should be runtime loadable dyanmic > > modules for "stuff". > > I hope to do it for eCAP (embedded ICAP) in Squid 3.1 if we get enough > interest in that feature. Our Traffic Spicer (written in C++) works with > d

Re: cvs commit: squid3 configure.in

Loadable dynamics modules maybe are not so important for existing features of squid3 (HTCP,ICAP or SNMP), but they are important to allow people/companies to extend squid. The eCAP interface sounds really a good idea. Also maybe there are others parts of squid which can extended in such way (eg AC

Re: cvs commit: squid3 configure.in

On Fri, 2007-09-07 at 09:43 +0800, Adrian Chadd wrote: > On Thu, Sep 06, 2007, Henrik Nordstrom wrote: > > > Maybe. I'll leave that to you to judge. Don't have a clear opinion > > either way. But why not? > > > > HTCP and SNMP is very non-intrusive, just enabling code which is never > > used unle

Re: cvs commit: squid3 configure.in

Kinkie wrote: > Watch out for Windows.. AFAIK in that OS it's not allowed to export > symbols from an executable image onto a DLL.. this is one of the reasons > why most complex applications in Windows are shipped as one huge DLL and > a stub executable. That's why you'd need to move all stuff po

Re: cvs commit: squid3 configure.in

On Fri, 2007-09-07 at 07:54 +0200, Pierangelo Masarati wrote: > The interface is minimal and it's pure C. Of course, it needs reverse > linking, so, for example, the function RegisterSetMyData() and any > other > function the module needs to see must be either exported by the main > to > the modul

Re: cvs commit: squid3 configure.in

Adrian Chadd wrote: > Ok, how's that work for exposing C++ interfaces in Squid to external > modules? Things could get quite ugly if you're going C++ -> C -> C++.. Perhaps I was unclear. There's no C++ -> C -> C++; the only C step is module_init(), which is called when the module is loaded and r

Re: cvs commit: squid3 configure.in

On Fri, Sep 07, 2007, Pierangelo Masarati wrote: > Adrian Chadd wrote: > > > Maybe one of the goals for squid-3.1 should be runtime loadable dyanmic > > modules for "stuff". > > > > (Although I'm not sure how well that'd work with C++ and its symbol > > munging..) > > I've some experience in thi

Re: cvs commit: squid3 configure.in

Adrian Chadd wrote: > Maybe one of the goals for squid-3.1 should be runtime loadable dyanmic > modules for "stuff". > > (Although I'm not sure how well that'd work with C++ and its symbol > munging..) I've some experience in this sense, . Initially, I was set

Re: cvs commit: squid3 configure.in

On Thu, Sep 06, 2007, Henrik Nordstrom wrote: > Maybe. I'll leave that to you to judge. Don't have a clear opinion > either way. But why not? > > HTCP and SNMP is very non-intrusive, just enabling code which is never > used unless configured in squid.conf, with no significant change in > other co

Re: cvs commit: squid3 configure.in

On tor, 2007-09-06 at 10:00 -0600, Alex Rousskov wrote: > On Mon, 2007-08-27 at 07:37 -0600, Henrik Nordstrom wrote: > > hno 2007/08/27 07:37:02 MDT > > Log: > > Enable HTCP and SNMP support by default in the binary, but default off in > > squid.conf > > Should we enable ICAP in the b

Re: cvs commit: squid3 configure.in

On Mon, 2007-08-27 at 07:37 -0600, Henrik Nordstrom wrote: > hno 2007/08/27 07:37:02 MDT > Log: > Enable HTCP and SNMP support by default in the binary, but default off in > squid.conf Should we enable ICAP in the binary by default as well? It is probably nearly as widely used as HTCP