You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dan Poirier <po...@pobox.com> on 2010/05/10 19:02:03 UTC
Reducing number of mod_lua hook directives
mod_lua has 8 separate directives for adding hooks using external files
with Lua code (LuaHookXxxxx) and 8 more for adding the same hooks using
inline Lua code (<LuaHookXxxxx>). Most of the code to implement these
is common.
I think it'd be easier to understand - and document - the module if we
cut these down to two directives, with an additional argument to
indicate which hook is involved. E.g. change
LuaHookAccessChecker /path/to/script.lua funcname
LuaHookAuthChecker /path/to/script.lua funcname
LuaHookCheckUserID /path/to/script.lua funcname
...
to
LuaHook AccessChecker /path/to/script.lua funcname
LuaHook AuthChecker /path/to/script.lua funcname
LuaHook CheckUserID /path/to/script.lua funcname
...
and
<LuaHookAccessChecker funcname>
-- lua code
</LuaHookAccessChecker>
to
<LuaHook AccessChecker funcname>
-- lua code
</LuaHook>
Thoughts?
Dan
Re: Reducing number of mod_lua hook directives
Posted by Dan Poirier <po...@pobox.com>.
You could go even farther, and just provide a way to run some Lua code
at startup, and provide Lua APIs to add hooks, handlers, or whatever
else you wanted.
But while as a programmer that sounds fine to me, I suspect for the
average user who just wants to add a few lines to tweak something, quite
possibly copying the configuration from a web site or a book, it's
easier if we provide a bit more of a framework for them.
Of course, the two options aren't mutually exclusive.
Re: Reducing number of mod_lua hook directives
Posted by "Akins, Brian" <Br...@turner.com>.
On 5/12/10 11:09 AM, "Brian McCallister" <br...@skife.org> wrote:
> Ah, but what happens when there are multiple functions for same hook?
> We could get into magic naming and scanning of global scope, but that
> really turns my stomach.
No need. It's easy. Think about it in lua, not C.
Something like this for a loader:
handlers = { }
-- mods is an array of modules. Probably passed in via post_config or
something. Hooks is an array of hook names
function load_stuff(mods, hooks)
-- try to load each mod like
local m = require 'modname'
-- now examine m for functions named in hooks
if m.functionname add to my array
end
Then in you runner something like
function hook_runner(r, hook_name)
-- look in handlers for hook_name. It should be an array of functions
-- call them, with r as the single argument until one returns something
-- other than declined
end
> Conceptually, we probably don't want different script authors
> stomping on each other anyway.
Forcing the use of modules rather than standalone scripts helps this some.
We loose a lot of the efficiencies of lua because of the design of worker,
prefork, event, etc. Lua Strings, memory, etc, per thread -- with lots of
threads - seems wasteful. But that's a larger discussion.
FWIW, I do a lot of lua now. We use it in almost every web server config
now.
--
Brian Akins
Re: Reducing number of mod_lua hook directives
Posted by Brian McCallister <br...@skife.org>.
On Tue, May 11, 2010 at 10:59 AM, Akins, Brian <Br...@turner.com> wrote:
> The hook runner itself should just be in lua. Instead of scripts, you write
> lua modules. If a lua module has a function with the correct names (ie,
> same as hooks) it uses that:
>
> Ie in my module foo
>
> function fixups( r )
> ....
>
>
> Would get called at fixups, etc.
>
>
> No need for a state per file, etc. Just have one state per thread.
Ah, but what happens when there are multiple functions for same hook?
We could get into magic naming and scanning of global scope, but that
really turns my stomach.
Speaking of lua_State instances, a problem I have not figured a nice
way around yet is how to say "it's okay to use this named one attached
to the scope rather than a new one" possibly with module separation.
Right now spinning up one per root file is not a huge deal as the
memory requirements for a lua_State are very small, but it would be
nice to have the option. In practice, when I have wanted this I have
just had one root and invoked different functions, and it has worked
fine. Conceptually, we probably don't want different script authors
stomping on each other anyway.
>
>
>
> --
> Brian Akins
>
>
Re: Reducing number of mod_lua hook directives
Posted by Dan Poirier <po...@pobox.com>.
On 2010-05-11 at 12:59, "Akins, Brian" <Br...@turner.com> wrote:
> The hook runner itself should just be in lua. Instead of scripts, you write
> lua modules. If a lua module has a function with the correct names (ie,
> same as hooks) it uses that:
>
> Ie in my module foo
>
> function fixups( r )
> ....
>
>
> Would get called at fixups, etc.
>
>
> No need for a state per file, etc. Just have one state per thread.
That sounds like a bigger change to how everything works. So we'd just
associate a Lua module with a configuration context, then any functions
defined in that module with names the same as hooks would get invoked in
those request phases?
Even if we don't go that far, I like the idea of just naming the
functions the same as the hooks, and not cluttering the configuration
with function names that most people will probably make the same as the
hook names anyway. Maybe we should just drop the function names from
the configuration.
Re: Reducing number of mod_lua hook directives
Posted by Brian McCallister <br...@skife.org>.
On Mon, May 10, 2010 at 2:03 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 5/10/2010 2:25 PM, Brian McCallister wrote:
>>> ...
>>>
>>> to
>>>
>>> LuaHook AccessChecker /path/to/script.lua funcname
>>> LuaHook AuthChecker /path/to/script.lua funcname
>>> LuaHook CheckUserID /path/to/script.lua funcname
>
> Any reason not to name the func before the script, especially since path names
> can get long winded, and I'm thinking C like decl funcname(args) {script}
That makes a lot of sense as well, actually.
>
Re: Reducing number of mod_lua hook directives
Posted by HyperHacker <hy...@gmail.com>.
On Tue, May 11, 2010 at 20:12, Dan Poirier <po...@pobox.com> wrote:
> On 2010-05-11 at 12:55, HyperHacker <hy...@gmail.com> wrote:
>> On Tue, May 11, 2010 at 08:47, Dan Poirier <po...@pobox.com> wrote:
>>> I just thought of a problem - right now, the funcname is optional
>>> (defaults to "handle"). I hate having optional arguments that don't
>>> come at the end. I'd just as soon make it a required argument, but if
>>> people would rather it stay optional, then I'd rather leave it at the
>>> end. What do folks prefer?
>>
>> I'd go for making it required, but is there a reason you have to
>> specify a function? Lua scripts usually start executing from the first
>> line in the file. It seems to me to make more sense to do that if a
>> function is not specified (or is "-" if it's a required argument).
>
> The request object is passed to the function as an argument, so there
> would have to be some other way to give the Lua code access to the
> request.
>
Say, the global variable Request or Server.Request?
--
Sent from my toaster.
Re: Reducing number of mod_lua hook directives
Posted by Dan Poirier <po...@pobox.com>.
On 2010-05-11 at 12:55, HyperHacker <hy...@gmail.com> wrote:
> On Tue, May 11, 2010 at 08:47, Dan Poirier <po...@pobox.com> wrote:
>> I just thought of a problem - right now, the funcname is optional
>> (defaults to "handle"). I hate having optional arguments that don't
>> come at the end. I'd just as soon make it a required argument, but if
>> people would rather it stay optional, then I'd rather leave it at the
>> end. What do folks prefer?
>
> I'd go for making it required, but is there a reason you have to
> specify a function? Lua scripts usually start executing from the first
> line in the file. It seems to me to make more sense to do that if a
> function is not specified (or is "-" if it's a required argument).
The request object is passed to the function as an argument, so there
would have to be some other way to give the Lua code access to the
request.
Re: Reducing number of mod_lua hook directives
Posted by HyperHacker <hy...@gmail.com>.
On Tue, May 11, 2010 at 08:47, Dan Poirier <po...@pobox.com> wrote:
> On 2010-05-11 at 08:52, Dan Poirier <po...@pobox.com> wrote:
>
>> On 2010-05-10 at 16:03, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>> On 5/10/2010 2:25 PM, Brian McCallister wrote:
>>>>> ...
>>>>>
>>>>> to
>>>>>
>>>>> LuaHook AccessChecker /path/to/script.lua funcname
>>>>> LuaHook AuthChecker /path/to/script.lua funcname
>>>>> LuaHook CheckUserID /path/to/script.lua funcname
>>>
>>> Any reason not to name the func before the script, especially since path names
>>> can get long winded, and I'm thinking C like decl funcname(args) {script}
>>
>> So we'd have
>>
>> LuaHook AccessChecker funcname /path/to/script.lua
>> <LuaHook AccessChecker funcname>
>
>
> I just thought of a problem - right now, the funcname is optional
> (defaults to "handle"). I hate having optional arguments that don't
> come at the end. I'd just as soon make it a required argument, but if
> people would rather it stay optional, then I'd rather leave it at the
> end. What do folks prefer?
>
> Dan
>
I'd go for making it required, but is there a reason you have to
specify a function? Lua scripts usually start executing from the first
line in the file. It seems to me to make more sense to do that if a
function is not specified (or is "-" if it's a required argument).
--
Sent from my toaster.
Re: Reducing number of mod_lua hook directives
Posted by Brian McCallister <br...@skife.org>.
On Tue, May 11, 2010 at 8:47 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 5/11/2010 9:47 AM, Dan Poirier wrote:
>>>
>>> LuaHook AccessChecker funcname /path/to/script.lua
>>
>> I just thought of a problem - right now, the funcname is optional
>> (defaults to "handle"). I hate having optional arguments that don't
>> come at the end. I'd just as soon make it a required argument, but if
>> people would rather it stay optional, then I'd rather leave it at the
>> end. What do folks prefer?
>
> I don't think this really violates the principal of adding optargs at the
> end of the directive. func names and paths appear sufficiently different.
The look different, yes, but not enough imho. Convention says your lua
files end in .lua, etc, but that is convention. While I don't feel
like being in the business of preventing fools from shooting
themselves in the foot, inspecting contents of a string to determine
if it is a function name or a path is pretty grody compared to
requiring the function name.
Requiring the function name reduces the "things you just have to know"
so I actually rather like it, the more I think about it.
>
Re: Reducing number of mod_lua hook directives
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/11/2010 9:47 AM, Dan Poirier wrote:
>>
>> LuaHook AccessChecker funcname /path/to/script.lua
>
> I just thought of a problem - right now, the funcname is optional
> (defaults to "handle"). I hate having optional arguments that don't
> come at the end. I'd just as soon make it a required argument, but if
> people would rather it stay optional, then I'd rather leave it at the
> end. What do folks prefer?
I don't think this really violates the principal of adding optargs at the
end of the directive. func names and paths appear sufficiently different.
Re: Reducing number of mod_lua hook directives
Posted by Dan Poirier <po...@pobox.com>.
On 2010-05-11 at 08:52, Dan Poirier <po...@pobox.com> wrote:
> On 2010-05-10 at 16:03, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>> On 5/10/2010 2:25 PM, Brian McCallister wrote:
>>>> ...
>>>>
>>>> to
>>>>
>>>> LuaHook AccessChecker /path/to/script.lua funcname
>>>> LuaHook AuthChecker /path/to/script.lua funcname
>>>> LuaHook CheckUserID /path/to/script.lua funcname
>>
>> Any reason not to name the func before the script, especially since path names
>> can get long winded, and I'm thinking C like decl funcname(args) {script}
>
> So we'd have
>
> LuaHook AccessChecker funcname /path/to/script.lua
> <LuaHook AccessChecker funcname>
I just thought of a problem - right now, the funcname is optional
(defaults to "handle"). I hate having optional arguments that don't
come at the end. I'd just as soon make it a required argument, but if
people would rather it stay optional, then I'd rather leave it at the
end. What do folks prefer?
Dan
Re: Reducing number of mod_lua hook directives
Posted by HyperHacker <hy...@gmail.com>.
On Tue, May 11, 2010 at 06:52, Dan Poirier <po...@pobox.com> wrote:
> On 2010-05-10 at 16:03, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>> On 5/10/2010 2:25 PM, Brian McCallister wrote:
>>>> ...
>>>>
>>>> to
>>>>
>>>> LuaHook AccessChecker /path/to/script.lua funcname
>>>> LuaHook AuthChecker /path/to/script.lua funcname
>>>> LuaHook CheckUserID /path/to/script.lua funcname
>>
>> Any reason not to name the func before the script, especially since path names
>> can get long winded, and I'm thinking C like decl funcname(args) {script}
>
> So we'd have
>
> LuaHook AccessChecker funcname /path/to/script.lua
>
> and (unchanged)
>
> <LuaHook AccessChecker funcname>
>
> which makes the two forms more consistent too. Sounds fine to me.
>
> Dan
>
+1. Really looking forward to Lua as a web server language.
--
Sent from my toaster.
Re: Reducing number of mod_lua hook directives
Posted by Dan Poirier <po...@pobox.com>.
On 2010-05-10 at 16:03, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> On 5/10/2010 2:25 PM, Brian McCallister wrote:
>>> ...
>>>
>>> to
>>>
>>> LuaHook AccessChecker /path/to/script.lua funcname
>>> LuaHook AuthChecker /path/to/script.lua funcname
>>> LuaHook CheckUserID /path/to/script.lua funcname
>
> Any reason not to name the func before the script, especially since path names
> can get long winded, and I'm thinking C like decl funcname(args) {script}
So we'd have
LuaHook AccessChecker funcname /path/to/script.lua
and (unchanged)
<LuaHook AccessChecker funcname>
which makes the two forms more consistent too. Sounds fine to me.
Dan
Re: Reducing number of mod_lua hook directives
Posted by "Akins, Brian" <Br...@turner.com>.
The hook runner itself should just be in lua. Instead of scripts, you write
lua modules. If a lua module has a function with the correct names (ie,
same as hooks) it uses that:
Ie in my module foo
function fixups( r )
....
Would get called at fixups, etc.
No need for a state per file, etc. Just have one state per thread.
--
Brian Akins
Re: Reducing number of mod_lua hook directives
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/10/2010 2:25 PM, Brian McCallister wrote:
>> ...
>>
>> to
>>
>> LuaHook AccessChecker /path/to/script.lua funcname
>> LuaHook AuthChecker /path/to/script.lua funcname
>> LuaHook CheckUserID /path/to/script.lua funcname
Any reason not to name the func before the script, especially since path names
can get long winded, and I'm thinking C like decl funcname(args) {script}
Re: Reducing number of mod_lua hook directives
Posted by Jorge Schrauwen <jo...@gmail.com>.
+1
~Jorge
On Mon, May 10, 2010 at 9:41 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Mon, May 10, 2010 at 3:25 PM, Brian McCallister <br...@skife.org>
> wrote:
> > On Mon, May 10, 2010 at 11:02 AM, Dan Poirier <po...@pobox.com> wrote:
> >> mod_lua has 8 separate directives for adding hooks using external files
> >> with Lua code (LuaHookXxxxx) and 8 more for adding the same hooks using
> >> inline Lua code (<LuaHookXxxxx>). Most of the code to implement these
> >> is common.
> >>
> >> I think it'd be easier to understand - and document - the module if we
> >> cut these down to two directives, with an additional argument to
> >> indicate which hook is involved. E.g. change
> >>
> >> LuaHookAccessChecker /path/to/script.lua funcname
> >> LuaHookAuthChecker /path/to/script.lua funcname
> >> LuaHookCheckUserID /path/to/script.lua funcname
> >> ...
> >>
> >> to
> >>
> >> LuaHook AccessChecker /path/to/script.lua funcname
> >> LuaHook AuthChecker /path/to/script.lua funcname
> >> LuaHook CheckUserID /path/to/script.lua funcname
> >
> > This makes a ton of sense to me.
>
> +1
>
Re: Reducing number of mod_lua hook directives
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, May 10, 2010 at 3:25 PM, Brian McCallister <br...@skife.org> wrote:
> On Mon, May 10, 2010 at 11:02 AM, Dan Poirier <po...@pobox.com> wrote:
>> mod_lua has 8 separate directives for adding hooks using external files
>> with Lua code (LuaHookXxxxx) and 8 more for adding the same hooks using
>> inline Lua code (<LuaHookXxxxx>). Most of the code to implement these
>> is common.
>>
>> I think it'd be easier to understand - and document - the module if we
>> cut these down to two directives, with an additional argument to
>> indicate which hook is involved. E.g. change
>>
>> LuaHookAccessChecker /path/to/script.lua funcname
>> LuaHookAuthChecker /path/to/script.lua funcname
>> LuaHookCheckUserID /path/to/script.lua funcname
>> ...
>>
>> to
>>
>> LuaHook AccessChecker /path/to/script.lua funcname
>> LuaHook AuthChecker /path/to/script.lua funcname
>> LuaHook CheckUserID /path/to/script.lua funcname
>
> This makes a ton of sense to me.
+1
Re: Reducing number of mod_lua hook directives
Posted by Brian McCallister <br...@skife.org>.
On Mon, May 10, 2010 at 11:02 AM, Dan Poirier <po...@pobox.com> wrote:
> mod_lua has 8 separate directives for adding hooks using external files
> with Lua code (LuaHookXxxxx) and 8 more for adding the same hooks using
> inline Lua code (<LuaHookXxxxx>). Most of the code to implement these
> is common.
>
> I think it'd be easier to understand - and document - the module if we
> cut these down to two directives, with an additional argument to
> indicate which hook is involved. E.g. change
>
> LuaHookAccessChecker /path/to/script.lua funcname
> LuaHookAuthChecker /path/to/script.lua funcname
> LuaHookCheckUserID /path/to/script.lua funcname
> ...
>
> to
>
> LuaHook AccessChecker /path/to/script.lua funcname
> LuaHook AuthChecker /path/to/script.lua funcname
> LuaHook CheckUserID /path/to/script.lua funcname
This makes a ton of sense to me.
> ...
>
>
> and
>
> <LuaHookAccessChecker funcname>
> -- lua code
> </LuaHookAccessChecker>
>
> to
>
> <LuaHook AccessChecker funcname>
> -- lua code
> </LuaHook>
>
>
> Thoughts?
>
> Dan
>
>
[SPAM] Re: Reducing number of mod_lua hook directives
Posted by Issac Goldstand <ma...@beamartyr.net>.
Spam detection software, running on the system "heartofgold.mirimar.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.
Content preview: On 5/10/2010 8:02 PM, Dan Poirier wrote: > mod_lua has 8 separate
directives for adding hooks using external files > with Lua code (LuaHookXxxxx)
and 8 more for adding the same hooks using > inline Lua code (<LuaHookXxxxx>).
Most of the code to implement these > is common. > > I think it'd be easier
to understand - and document - the module if we > cut these down to two directives,
with an additional argument to > indicate which hook is involved. E.g. change
> [snip] > > > Thoughts? > > Dan > Maybe so, and maybe no... The mod_perl
community, for example, has all of these names. It makes it easier for newbies
to distinguish between the directives, I think. But maybe I'm biased because
I got "into" the C API coming from mod_perl... [...]
Content analysis details: (5.5 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT
[79.183.201.141 listed in bb.barracudacentral.org]
3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[79.183.201.141 listed in zen.spamhaus.org]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
1.0 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS
1.0 TO_NO_BRKTS_DYNIP TO_NO_BRKTS_DYNIP