Re: Apache config for compiled modules

On Monday, February 17, 2003, at 05:15  PM, Shay Harding wrote:

> 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).
>
Don't different stages of the apache life cycle have different inputs 
and outputs ? I'm not sure if an embedded language like moto is really 
well suited for url-rewriting or authentication. Where does the output 
go ?

> 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 is interesting. If there are two compiled modules would both of 
them see the Session.Disable directive ? Is it a true apache directive 
in this case ? Would config options need to be registered somewhere 
special like apache directives need to be ?

> 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.
>
Is SetHandler implicit with this syntax ?

>
> 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
>
yeah ... that would be kindof a hairball ... also the interpreter would 
need to be changed as well so handlers could be tested.

> 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?
>

I'm not convinced about the whole stage handler thing. It sounds really 
hard :) and I'm not sure moto is the right tool for the job (although I 
have no doubt it could be forced to perform it :) ). The block style 
syntax is really interesting though. I'd like to hear more about that!

-Dave

>
>
>
> 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
>
>
>