You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Querna <pa...@querna.org> on 2009/03/31 01:37:09 UTC
what is in modules vs what is in the core
mod_watchdog is the latest offender in a series of modules that expose
additional functions to the API. (mod_proxy and mod_cache do too!)
What happened to all functions that are not inside server/* must be
either dynamic optional functions or hooks?
Doesn't anyone remember the load order pain of apache 1.3?
Are we just getting lazy, or does it not matter to anyone now days?
Thanks,
Paul
RE: what is in modules vs what is in the core
Posted by David Martínez Albiter <da...@insys-corp.com.mx>.
prueba
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: Lunes, 30 de Marzo de 2009 08:03 p.m.
To: dev@httpd.apache.org
Subject: Re: what is in modules vs what is in the core
Paul Querna wrote:
> mod_watchdog is the latest offender in a series of modules that expose
> additional functions to the API. (mod_proxy and mod_cache do too!)
>
> What happened to all functions that are not inside server/* must be
> either dynamic optional functions or hooks?
>
> Doesn't anyone remember the load order pain of apache 1.3?
>
> Are we just getting lazy, or does it not matter to anyone now days?
Or perhaps it's just a bug?
Regards,
Graham
--
Re: what is in modules vs what is in the core
Posted by Graham Leggett <mi...@sharp.fm>.
Paul Querna wrote:
> mod_watchdog is the latest offender in a series of modules that expose
> additional functions to the API. (mod_proxy and mod_cache do too!)
>
> What happened to all functions that are not inside server/* must be
> either dynamic optional functions or hooks?
>
> Doesn't anyone remember the load order pain of apache 1.3?
>
> Are we just getting lazy, or does it not matter to anyone now days?
Or perhaps it's just a bug?
Regards,
Graham
--
Re: what is in modules vs what is in the core
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Paul Querna
> Gesendet: Dienstag, 31. März 2009 01:37
> An: dev@httpd.apache.org
> Betreff: what is in modules vs what is in the core
>
> mod_watchdog is the latest offender in a series of modules that expose
> additional functions to the API. (mod_proxy and mod_cache do too!)
Which functions do you have in mind regarding mod_proxy / mod_cache?
>
> What happened to all functions that are not inside server/* must be
> either dynamic optional functions or hooks?
I wasn't aware of this rule but it make much sense to me.
>
> Doesn't anyone remember the load order pain of apache 1.3?
>
> Are we just getting lazy, or does it not matter to anyone now days?
I guess we are just getting lazy here and must pay more attention to these
points.
Regards
Rüdiger
Re: what is in modules vs what is in the core
Posted by Mladen Turk <mt...@apache.org>.
Paul Querna wrote:
> mod_watchdog is the latest offender in a series of modules that expose
> additional functions to the API. (mod_proxy and mod_cache do too!)
>
So, you came back from different direction, cool :)
If you really like to put the watchdog functionality
inside the mpm (and IMO that's all this about, sorry if I got
the wrong impression) then the mpm api needs to get
extended and implemented by *all* mpm's.
>
> Are we just getting lazy, or does it not matter to anyone now days?
>
IIRC you wish to use the watchdog directly from simple mpm,
redesign the watchdog api so that it can be used from
simple mpm at the first place, and leave to the others to
cope with the rest.
I would personally love to see the watchdog (actually
generic event ap_listener) functionality in the mpm's
core, and my first thing on the todo list is to extend
the mpm with child singleton hook. Just like we have
child_init we would have child_singleton_init hook but run
only for a single child, and run again once for the
next one when the previous dies. That way we would get
rid of all the singleton and startup mutex hacks, to
obtain something that is inherently known by the mpm.
However this needs to be implemented inside each and
every mpm if we wish to have any sort of the api.
Other solutions would be to simply move the
mod_watchdog to server/watchdog.c or that we all
just use the simple mpm :)
Regards
--
^(TM)
Re: Lua and memcache was Re: what is in modules vs what is in the
core
Posted by "Akins, Brian" <Br...@turner.com>.
On 3/31/09 10:18 AM, "Bertrand Mansion" <bm...@mamasam.net> wrote:
> Reading the comments in your code, it seems that mod_lua could benefit
> from a better error reporting ?
Perhaps. Or I just needed to actually add error checking.... Right now I
rely on the lua side to sanity check stuff.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: Lua and memcache was Re: what is in modules vs what is in the core
Posted by Bertrand Mansion <bm...@mamasam.net>.
Le 31 mars 09 à 15:52, Akins, Brian a écrit :
>
>> OT, but will you contribute that to mod_lua ? :)
>
> Based on mod_memcache and mod_wombat . For demonstration only as
> this uses
> our hacked version, but you get the idea how simple this was. Build
> it in
> lua dir like /usr/lib/lua/5.1/apach2/memcache.so
Thank you :)
That's probably the way support for apr_(date, file, dbd ...) will be
added to mod_lua.
Reading the comments in your code, it seems that mod_lua could benefit
from a better error reporting ?
--
Bertrand Mansion
Mamasam
Tel : +33 1 48 89 88 26
http://www.mamasam.com
Lua and memcache was Re: what is in modules vs what is in the core
Posted by "Akins, Brian" <Br...@turner.com>.
> OT, but will you contribute that to mod_lua ? :)
Based on mod_memcache and mod_wombat . For demonstration only as this uses
our hacked version, but you get the idea how simple this was. Build it in
lua dir like /usr/lib/lua/5.1/apach2/memcache.so
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: what is in modules vs what is in the core
Posted by Bertrand Mansion <bm...@mamasam.net>.
On Tue, Mar 31, 2009 at 4:25 AM, M. Brian Akins <br...@akins.org> wrote:
> As I hack on some lua stuff, it's useful to have the symbols for functions.
> That may just be because I'm lazy, because I could do optional function
> lookups in library opens, I suppose. OT, but I like my Lua glue in a lua
> module and just use "require 'apache2.memcache'" (or whatever) to do the
> linking. This works really well with per thread lua states that are all
> loaded at startup... (hint, hint)
OT, but will you contribute that to mod_lua ? :)
--
Bertrand Mansion
Mamasam
Re: what is in modules vs what is in the core
Posted by Jorge Schrauwen <jo...@gmail.com>.
Maybe a more layered approach would be something to consider for 3.0?
Seems to me that the layers and groups of modules keeps expanding and expanding.
2.0 -> 2.2 had the whole auth move over so maybe it's time to rethink
the current module system for 3.0?
~Jorge
On Tue, Mar 31, 2009 at 4:25 AM, M. Brian Akins <br...@akins.org> wrote:
>
> On Mar 30, 2009, at 7:37 PM, Paul Querna wrote:
>
>> mod_watchdog is the latest offender in a series of modules that expose
>> additional functions to the API. (mod_proxy and mod_cache do too!)
>>
>> What happened to all functions that are not inside server/* must be
>> either dynamic optional functions or hooks?
>
>
> Some modules (mostly 3rd party??) allow it either way - optional function or
> just linkage. I'm personally a fan of hooks and providers. (With
> providers, I usually just do the lookup once in, say, post-config, and
> "cache" the results in the "subscribing" module - this saves some hash
> lookups on potentially every single request.)
>
> As I hack on some lua stuff, it's useful to have the symbols for functions.
> That may just be because I'm lazy, because I could do optional function
> lookups in library opens, I suppose. OT, but I like my Lua glue in a lua
> module and just use "require 'apache2.memcache'" (or whatever) to do the
> linking. This works really well with per thread lua states that are all
> loaded at startup... (hint, hint)
>
> --Brian
>
Re: what is in modules vs what is in the core
Posted by "M. Brian Akins" <br...@akins.org>.
On Mar 30, 2009, at 7:37 PM, Paul Querna wrote:
> mod_watchdog is the latest offender in a series of modules that expose
> additional functions to the API. (mod_proxy and mod_cache do too!)
>
> What happened to all functions that are not inside server/* must be
> either dynamic optional functions or hooks?
Some modules (mostly 3rd party??) allow it either way - optional
function or just linkage. I'm personally a fan of hooks and
providers. (With providers, I usually just do the lookup once in,
say, post-config, and "cache" the results in the "subscribing" module
- this saves some hash lookups on potentially every single request.)
As I hack on some lua stuff, it's useful to have the symbols for
functions. That may just be because I'm lazy, because I could do
optional function lookups in library opens, I suppose. OT, but I like
my Lua glue in a lua module and just use "require
'apache2.memcache'" (or whatever) to do the linking. This works
really well with per thread lua states that are all loaded at
startup... (hint, hint)
--Brian