You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian McCallister <br...@apache.org> on 2007/04/13 21:04:23 UTC
mod_wombat import complete
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?
-Brian
Re: mod_wombat import complete
Posted by Paul Querna <ch...@force-elite.com>.
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