Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <51790532.6010208@cord.dk>
Date: Thu, 25 Apr 2013 12:28:02 +0200
From: Daniel Gruno <rumble@cord.dk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r1469852 -
 /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
References: <20130419143151.A4B2F23889FA@eris.apache.org>
 <5171DAE1.9090102@apache.org> <51723CAE.9030100@cord.dk>
 <517701E0.40203@apache.org> <517708B4.9040804@apache.org>
 <5178FD69.7030300@cord.dk>
In-Reply-To: <5178FD69.7030300@cord.dk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

On 04/25/2013 11:54 AM, Daniel Gruno wrote:
> On 04/24/2013 12:18 AM, Guenter Knauf wrote:
>> On 23.04.2013 23:49, Guenter Knauf wrote:
>>> Hi Daniel,
>>> On 20.04.2013 08:58, Daniel Gruno wrote:
>>>> Thanks for the invaluable help, it's really good knowing there's someone
>>>> else taking such an interest in this project! :) I hope that someday we
>>>> can shed mod_lua of its experimental status and people won't think me a
>>>> crazy person for recommending it left and right ;)
>>> naa, I find the module useful too for all sorts of smaller tasks as well
>>> as special httpd things which otherwise can only be done with a C module
>>> I believe ...
>>> now since I looked a bit at the code here and there I think there are
>>> some things which we should fix over the next months ...
>>>
>>> 1) the code formatting is not yet at our standard
>>> 2) the 'apache2' module does pollute the global table, and at 1st glance
>>> with my limited Lua experience I dont see why this happens; I've tested
>>> with other dynamically loaded modules like geoip, socket and apr (yeah,
>>> there exists a *very* *great* APR binding! [1]), and they all only
>>> create their own table and nothing global; it would be nice if we could
>>> either teach the apache2 module to behave same, or at least make it
>>> prelinked/preloaded and let it only plug in when enabled via 'require'.
>>> See attached script which shows what I mean ...
>>> 3) Since there exists a well done and well functioning APR binding we
>>> should probably consider to add some code to mod_lua so that its
>>> possible to prelink/preload this APR binding once at module start
>>> instead of loading it from every script again and again ...
>>> if we would agree on that we could even ditch a bunch of the recent APR
>>> adds, thus making mod_lua itself cleaner / smaller again + we would get
>>> almost the full power of APR into mod_lua ...
>>>
>>> G�n.
>>>
>>> [1] http://peterodding.com/code/lua/apr/
>>
>> and two more things:
>> 1) I found with my script that there is also a table apr_table created
>> with methods get and set but its not yet documented
>> 2) I wonder why we do export some functions from mod_lua, and what could
>> make use of these?
>> But then again this is only a Lua newbie question, and I dont know
>> enough about the load process of mod_lua specially on Windows with its
>> external dependency to the Lua DLL and how this exactly works, probably
>> these exports are needed for Windows?
>>
>> G�n.
>>
>>
>>
> Windows has a ton of crap requirements for mod_lua to work properly.
> Enough said :(
> 
> I'll look into that apr_table thing, I can't remember what it does off
> the top of my head.
> 
> With regards,
> Daniel.
> 
Okay, it seems that the apr_table thing is some leftover from old code -
I'll see if I can safely remove the thing (lua_apr.c could probably be
removed entirely) and do so when I have the cycles.

With regards,
Daniel.