[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    Re: dynamic modules
From:       "Robert Collins" <robert.collins () itdomain ! com ! au>
Date:       2001-01-30 22:24:15
Message-ID: 01a601c08b0b$62eb1ad0$0200a8c0 () lifelesswks
[Download RAW message or body]

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Wednesday, January 31, 2001 8:43 AM
Subject: Re: dynamic modules


> Robert Collins wrote:
> 
> > anyone think that dynamic modules are a good thing/bad thing?
> 
> I am in favor of it, with interfaces for at least
> 
> * object store
> * removal policy
> * reply filters
> * request filters (extrapolation of redirectors)
> -] Already partially there...
> * ACL types

Right. We're thinking along the same sort of lines. I am planning to put the module \
framework code in one place, with a defined API, and each module calls one or more \
registration functions - one for each of the types above.

> 
> To allow for this, a few APIs of Squid should be formalized:
> 
> * how to register for filedescriptor events
> * how to open files/sockets/pipes
> * how to sleep (time events).

Are these not formalised at the moment? How generic can we be? I.E. is there any \
reason we can't simply specify that to sleep, use add_event, to block use a callback \
approach combined with the current fd routines? Or Did you mean we just need to write \
how-to-use-the-existing-routines down in the writing modules guide? What I'm trying \
to say, is these issues already exist for the fs,repl,auth modules today : what do we \
need to do in a minimalistic sense that is different?

> 
> I am also in favor for using dynamic linking in bringing these modules
> in, but dynamic linking should be a optional feature, allowing for a
> static binary to be built with all the required modules linked in from
> start.

Agreed. For secure setups dynamic loading is bad IMO.

Rob


[prev in list] [next in list] [prev in thread] [next in thread]