LuaSet: good or terrible idea?

[Daniel Gruno <ru...@cord.dk>]

Dear dev@,
I've been looking into mod_lua for some time now, and have created an
external library with lot of functions that make use of the AP/APR C API
(such as ap_expr calls, scoreboard reading, sha1/md5/b64 functions, dbd
and sendfile support etc). While doing so, I've also thought about how
to improve mod_lua itself, but I now find myself doubting my own
reasoning for committing a directive to the code.

The directive would/could be called LuaSet, and would set a variable
that is only accessible through Lua, much like mod_perl has PerlSetVar,
and mod_php has...whatever it has. The idea was that you could do
something like:

LuaSet foo on
<Location /nothere>
  LuaSet foo off
</Location>

and then retrieve that value inside your Lua scripts using something
like r:parseenv() to get a table of Lua-specific values that applied to
that scope.

However, this could also be managed by using SetEnv or SetEnvIf (if you
hook something real early) and then fetched through r.subprocess_env. So
the question is; Should I bother committing this directive, or is it
just a redundant function?

On the plus side, it makes it easy in the configuration to spot Lua
specific values and ensures that it doesn't clash with other env
variables that might have been set, and on the other hand, one could
just do something like SetEnv Lua_foo on.

So what say you, is it a good or a terribly redundant idea?

With regards,
Daniel.

Re: LuaSet: good or terrible idea?

[Ruediger Pluem <rp...@apache.org>]

Daniel Gruno wrote:
> Dear dev@,
> I've been looking into mod_lua for some time now, and have created an
> external library with lot of functions that make use of the AP/APR C API
> (such as ap_expr calls, scoreboard reading, sha1/md5/b64 functions, dbd
> and sendfile support etc). While doing so, I've also thought about how
> to improve mod_lua itself, but I now find myself doubting my own
> reasoning for committing a directive to the code.
> 
> The directive would/could be called LuaSet, and would set a variable
> that is only accessible through Lua, much like mod_perl has PerlSetVar,
> and mod_php has...whatever it has. The idea was that you could do
> something like:
> 
> LuaSet foo on
> <Location /nothere>
>   LuaSet foo off
> </Location>
> 
> and then retrieve that value inside your Lua scripts using something
> like r:parseenv() to get a table of Lua-specific values that applied to
> that scope.
> 
> However, this could also be managed by using SetEnv or SetEnvIf (if you
> hook something real early) and then fetched through r.subprocess_env. So
> the question is; Should I bother committing this directive, or is it
> just a redundant function?
> 
> On the plus side, it makes it easy in the configuration to spot Lua
> specific values and ensures that it doesn't clash with other env
> variables that might have been set, and on the other hand, one could
> just do something like SetEnv Lua_foo on.
> 
> So what say you, is it a good or a terribly redundant idea?
> 

IMHO there should be no Lua specific directive if setenv / setenvif can do the same.

Regards

Rüdiger

Re: LuaSet: good or terrible idea?

[Bertrand Mansion <bm...@mamasam.net>]

Iirc php has php_value and php_admin_value but they are used to override
parameters set in the php.ini file so that's not the same.

For apr and lua see peterodding.com/code/lua/apr/docs/

Bertrand Mansion
Mamasam
 Le 24 juil. 2012 19:28, "Daniel Gruno" <ru...@cord.dk> a écrit :

> Dear dev@,
> I've been looking into mod_lua for some time now, and have created an
> external library with lot of functions that make use of the AP/APR C API
> (such as ap_expr calls, scoreboard reading, sha1/md5/b64 functions, dbd
> and sendfile support etc). While doing so, I've also thought about how
> to improve mod_lua itself, but I now find myself doubting my own
> reasoning for committing a directive to the code.
>
> The directive would/could be called LuaSet, and would set a variable
> that is only accessible through Lua, much like mod_perl has PerlSetVar,
> and mod_php has...whatever it has. The idea was that you could do
> something like:
>
> LuaSet foo on
> <Location /nothere>
>   LuaSet foo off
> </Location>
>
> and then retrieve that value inside your Lua scripts using something
> like r:parseenv() to get a table of Lua-specific values that applied to
> that scope.
>
> However, this could also be managed by using SetEnv or SetEnvIf (if you
> hook something real early) and then fetched through r.subprocess_env. So
> the question is; Should I bother committing this directive, or is it
> just a redundant function?
>
> On the plus side, it makes it easy in the configuration to spot Lua
> specific values and ensures that it doesn't clash with other env
> variables that might have been set, and on the other hand, one could
> just do something like SetEnv Lua_foo on.
>
> So what say you, is it a good or a terribly redundant idea?
>
> With regards,
> Daniel.
>