Brian McCallister wrote: > Finally finished up the import of mod_wombat into httpd svn ( > http://svn.apache.org/repos/asf/httpd/mod_wombat ). > > The code has been idle while going through the software grant process in > the incubator. Now that it is here I am eager to start working on it again. > > There are a couple design issues I want to rethink, mostly in the > handling of lua vm creation, right now. Presently it uses a vm > specification approach where you create a struct with the various knobs > that can be applied. It basically means filling out three to five fields > in a struct and passing it to one of a couple methods depending on the > scope you are operating in (request, connection, server). Right now > there is a pretty big matrix of options and it smells kind of fishy to > me. I think something simpler can be done, but the range of options look > valid: > > * lifecycle of vm (one shot, request, connection, or server) > * code caching (load it and forget about it vs stat per new vm, vs load > per new vm) > * file which contains root source for the vm being constructed > * array or load paths for the vm > > The mod_php approach of "you just get request scoped, deal with it" is > kind of appealing in its simplicity, on the other hand. > > Thoughts?
I think the request scoped, deal with it, is the best _default_ mode. It is simple, and you avoid lots of complicated thinking. I think that the flexibility given by the ability to make persistent variables and such, per connection or for the lifetime of a process is very powerful, and I would like to keep it. Also note, that the bytecode compilation shouldn't be tied to the lifetime of a VM.... since you can just compile the bytecode, and stick it in a char* for later use... For example, a <Directory or <VirtualHost context could be precompiled on startup.... But the lifetime of the VM to run that could be per-request. -Paul
