Apache config for compiled modules

I've been messing with how the compiled modules work and was wondering if
this sounds like a good idea or not:

Right now all modules act as Apache content-handlers. They cannot intercept
requests as they fire at basically the end of the Apache life-cycle. I'd
like to see this change to where you can specify, via httpd.conf, where the
module appears in the Apache handlers (i.e. access, authentication,
url-rewriting, content, etc).

The following config is an idea to begin to accomplish this:

XXX = compiled module name

<XXXLocation /myloc>
	SharedHeapSize    32M
	Session.Disable	TRUE
	MotoAccessHandler	xxx
</XXXLocation>


This can appear in any <Location> or <Directory> tags if needed:

<Location /mymainloc>
    <XXXLocation /myloc>
		SharedHeapSize    32M
		Session.Disable	TRUE
		MotoAccessHandler	xxx
    </XXXLocation>

    SetHandler someotheraccesshandler
</Location>


This would allow to do whatever Apache processing you needed for
"/mymainloc" and for "/mymainloc/myloc" a Moto handler is processed. The
above config setup is two-fold: 1) it gets rid of "MotoOption Location", 2)
gets rid of the syntax "MotoOption ActualOption Value" and 3) can be used
like Apache's "<Location>" OR "<Directory>" tags:

<MotoLocation /var/tmp>

--OR--

<MotoLocation /my/uri>

By using the Apache API internal function ap_is_directory() we can tell
which is being used.


How to get the compiled code to produce the correct handler functions is
still undecided as it seems to need options in mmc to tell it how to produce
the compiled code. Like:

mmc --handler access ...
mmc --handler content ...
etc

So the correct entry is filled in for the Apache module structure. This
would make the "MotoXXXHandler" config useless for compiled modules.

Getting this to work with interpreted code is a bit more complex I think as
mod_moto would have to parse "<MotoLocation>" tags and actually create its
own internal handler chain using the "MotoXXXHandler" directives. These
would appear as:

MotoAccessHandler		code.moto

--OR--

MotoAccessHandler		code.moto->function

This would appear in a "<MotoLocation>" tag so we know where "code.moto" is
sitting.


By allowing the second construct you can have 1 moto file handle many
situations. This also means that a lot of the Apache internals need to be
accessible from within Moto space. I think the current executeTemplate()
logic could be used to parse individual functions within a moto file, but
I'm sure it would require some changes. Interpreted moto files would define
(by default) a function:

int handler(HttpRequest r){}

so the config:

MotoAccessHandler		code.moto

really calls:

code.moto->handler(HttpRequest r)


Like I said, it's just a rough idea, but seems doable. Any thoughts,
suggestions, etc?




Shay

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.455 / Virus Database: 255 - Release Date: 2/13/2003