2009/6/9 Jorge Schrauwen <jorge.schrau...@gmail.com>:
> As long as the current system isn't replaced by an entire runtime like
> program approach I'd be okay with it.
>
> But why not take it a step further than just lua?
> Wouldn't it be possible to expose a standardized set of commands,
> functions, objects, whatnot to any language?
The standard objects are things like request_rec, server_rec etc etc.
Ie., Apache's own internal data structures. Modules such as mod_perl
and mod_python provide wrappers for these. The standardised set of
commands are the Apache and APR functions which are also wrapped.
Or are you talking about higher level functionality. A lot of higher
level functionality is I understand provided in modules associated
with mod_perl already. In other words, at the moment any higher levels
encapsulation of functionality up to the specific script language
module. Some provide more than others.
Graham
> That start with mod_lua as the initial implementation but if at a
> later date someone makes mod_lisp/mod_java/.. they all share about the
> same objects where just the syntax would be different. Also the glue
> would then also extend to not just lua.
>
> That would also help to make it documenting it language independently
> more doable. (wow thats a word?)
>
> you could then talk about a "request" object having properties x,y and
> z and it doesn't matter if you manipulate it via lua,java,perl
>
> Then again this would probably cause a whole lot of overhead and would
> force mod_lua to be rewriting a lot I guess.
>
>
> ~Jorge
>
>
>
> On Tue, Jun 9, 2009 at 2:49 PM, Akins, Brian<brian.ak...@turner.com> wrote:
>> On 6/5/09 11:31 PM, "Graham Dumpleton" <graham.dumple...@gmail.com> wrote:
>>
>>> This last example wasn't even related to driving configuration. It was
>>> in practice an actual handler hook implementation for request
>>> processing, not configuration phases.
>>
>> The way I see it, we have artificially separated configuration from request
>> processing. If you squint and tilt your head just right, you can see that
>> virtualhosts today are really just syntactical sugar over the if/else logic
>> inside of core:
>>
>> Some pseudo request processing code to do same thing:
>> if listening_port == 80 then
>> if r.hostname == 'www.foo.com' then
>> ....
>> elseif r.hostname =~ /www\d.bar.[org|net]/
>> end
>> end
>>
>>
>> Of course this could be further hidden from users with
>> macros/functions/libraries/modules...
>>
>> Now, on the practical side, do we completely ditch the current config
>> system. Part of me says yes, but I know that will be -1'd to death. So,
>> I'd just like the ability to do something like this:
>>
>> LoadModule lua_module mod_lua.so
>> Listen 80
>> LuaRequestHandler /path/to/my/lua/handler.lua
>>
>> (or it can be inline <Lua> but have found that to be somewhat cumbersome)
>>
>> Because I don't want to rewrite mod_proxy in lua, it'd be nice to have just
>> a little bit of glue that would allow me to use it in a more "scripty" sort
>> of way:
>>
>> LoadModule proxy_module mod_proxy.so
>> LoadModule proxy_http_module mod_proxy_http.so
>> ....
>> require httpd.proxy -- provided by mod_proxy glue
>>
>> p = httpd.proxy.get_url('http://blah')
>>
>>
>> (Of course, that example could be handled like we do in mod_rewrite)
>>
>> Currently, we can sorta do most request processing in lua. (FWIW, do the
>> request phases make any sense in a world where the entire request process is
>> handled by a "script"??) What is missing is the glue to the other, useful
>> parts of httpd - like cache, mod_dbd, proxy, etc.
>>
>> Sure, one of us could hack together some example glue here and there, but
>> until we as a whole "get" why this is useful/important, it will be just
>> another list of patches waiting to be reviewed.
>>
>> --
>> Brian Akins
>> Chief Operations Engineer
>> Turner Digital Media Technologies
>>
>>
>
