On 08/22/2012 01:36 PM, Nick Kew wrote: > > Basic concept looks fine. I guess we'd need more detail > to say any more about it. > > Is the implementation 'clean' or does it involve hacks to core? > If what you have is pure module then I'd see no reason > not to drop mod_lua_filter (or is it mod_filter_lua?) > into trunk on CTR.
I don't see why it should be made a separate module - it relies and operates on the stuff already inside mod_lua, and making it a part of it only requires adding some 50-60 lines of code (ymmv). But ideas/opinions are of course welcome. As for the 'cleanliness' of the code, there are no hacks, it works similar to how the other hook functions in mod_lua work. Each call to a Lua(In|Out)putFilter would register a new filter with a callback to fx ap_lua_output_filter, which will then traverse a list of known scripts/handles, find the one associated with the filter name in question and run it, making the Lua script yield whenever it's parsed a bucket and sending it further down the chain. Apart from the actual bucket handling, the function and the directives behave just as the other hooks and the LuaMapHandler does. When called, it would register a file/function in an array, and when a call is made to that handler, it checks to see what is being called, and finds the file/function associated with it. i.e. if you had two directives: LuaOutputFilter filterA /www/filters.lua filter_a_func LuaOutputFilter filterB /www/filters.lua filter_b_func then an output, with any of those two filters attached, would call ap_lua_output_filter, which would look up the filter currently being run and then run the file/function mapped to that filter. I guess what separates this from the other hooks the most is that it relies on co-routines (aka non-blocking/event-based or whatever the newest buzz word for it is) to get the job done. > > Meanwhile, some random thoughts: > > Is there a deep reason to limit it to output filters, or is that > just what you happen to have implemented? The same method could be applied to input filters as well, I just had an interest in trying it out for output filters, so that's what I hacked together before making this proposal. I'll try implementing an input filter tomorrow. > > Would your concept meaningfully generalise beyond > application-level filters? > I'm not entirely sure what you mean by this, could you elaborate? If you want some more sophisticated examples of what could be achieved with Lua filtering, I'd be happy to provide some more details on how this concept could be utilised. With regards, Daniel.
