Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <519FDF7A.2030003@cord.dk>
Date: Fri, 24 May 2013 23:45:30 +0200
From: Daniel Gruno <rumble@cord.dk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Time for 2.4.5 ??
References: <E77566CC-52C2-4128-B9AE-A112303BCEA3@jaguNET.com>
 <20130522160511.630b76f0@hub>
 <F8E57728-CC27-4B18-A2A4-DE960E570CF0@jaguNET.com>
 <519FB92C.9070101@apache.org>
In-Reply-To: <519FB92C.9070101@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

On 05/24/2013 09:02 PM, Guenter Knauf wrote:
> On 24.05.2013 14:40, Jim Jagielski wrote:
>> There are a few things I'd like to see in 2.4.5, which would
>> be significant for the 2.4.x release:
>>
>>    o The mod_lua stuff
> ok, after spending a bunch of hours during last weeks with testing
> mod_lua mainly on Windows I've finally removed my blocking vote from
> STATUS just now; nevertheless I feel that I did only test half of all
> the new stuff, and therefore my vote is +0.5 only ...
> some things which I see as outstanding are:
> - removal of the export declarations since they are unneeded (I will
> take a look into this during this weekend if nobody beats me)
> - removal of some doubled code ( ap_lua_check_request_rec() )
> - another docu fix for r:sleep() --> r.sleep(); meanwhile I have a
> stronger oppinion about this: I believe we should chage all functions to
> r:function() in order to separate them more clearly from vars like
> r.filename; 

I can only say +1 from me, we need consistency here :)

further more I believe r.sleep() would be better renamed to
> r.usleep() taking microseconds instead of having a r.sleep() and then
> dealing with fractions of seconds - this way also the code would be
> cleaner and no calculation of the passed-in value needed anymore, just
> the value would get passed to apr_sleep().
> 

That's fine by me, I'm not married to 'sleep' (although I do like a good
nap)

> Optional: I really would like to also have DBM support in addition to
> the DBD support, but unfortunately I had not the time yet to look into
> it ...
> 
I've not looked in APR, but I assume this is something supported in
there? Perhaps if you could come up with a sketch/mock api, we could get
started on this?

> So how do we further proceed with mod_lua? There are certainly some
> remaining issues, but it just takes too long for only 2 persons to find
> them all; also I see with current code that it works fine when I compile
> it with MSVC6 while compiled MSVC9 it crashes when things go wrong - not
> sure yet if this is an issue with MSVC9 itself, or with the converted
> projects ...;

I ran into some issues with MSVC10/11, but they appear to have been
fixed (though not 100% sure) - but I'm not a big Windows expert anymore :|

 I think we should now copy over the complete trunk code to
> 2.4.x branch, and keep the status 'experimental' so that users are
> warned that directives, functions, etc. might change even with an
> otherwise stable release branch;
> hopefully then when more users play with mod_lua we will make faster
> progress with finding any further issues ...
> 
> also given that currently only Daniel and I (and Gregg with some
> testing) care about mod_lua I would like that we make an exception for
> this module so that we can backport any further modifications and fixes
> directly to the 2.4.x branch until we declare the module as stable and
> non-experimental.
> 
> G�n.
> 
> 
> 

With regards,
Daniel.