Re: Apache config for compiled modules

	I want to apologize for avoiding my email lately. I've been underwater 
trying to push through the HOF implementation. It looks like I've 
passed the final major roadblock at this point. The 'def' keyword has 
been removed :) . If all goes well I'll be merging the HOF branch back 
to the main branch by days end.

Re: Apache config changes and stage handlers

	So my concerns with using moto to write apache come down to the 
following :

0) Is it necessary ? I don't know nearly enough about this but it 
strikes me that url rewriting and page execution for the purpose of 
access control don't really fall under moto's core competencies. If it 
is possible to get this functionality by using other modules in concert 
with moto e.g. mod_rewrite than I would rather not go down the road of 
adding this functionality to moto modules at the moment.

1) Stage handlers are web server specific and would likely have to be 
written very differently for different web servers including Apache 2.

2) Without having the ability to test handlers in the interpreter we 
lose parity which I've been very careful to maintain. Without parity in 
the interpreter and compiler the model of rapid design and testing in 
interpreted mode followed by a compilation and subsequent push to 
production no longer works. If moto is going to support stage handling 
we need parity.

3) I would argue that all moto pages output something. This is inherent 
in the design of moto as an embedded language. Treating a page as a 
function, which is really what were doing when we try and make it a 
stage handler, strikes me as odd. Different stages have different 
inputs and look for different types of values to be returned (or 
response fields to be set).

If there is a necessity to write apache handlers in moto I would be 
much more comfortable registering functions as opposed to pages to 
handle them. This strategy would address the input output issue and 
possibly parity as well. It would also mirror the C API and be very 
similar to the way things are done with Java Servlets as well. Some of 
the code necessary to accomplish this has been done on the Higher Order 
Functions branch. With the HOF changes you can pass Function objects in 
C which encapsulate an interpreted, compiled, or externally defined 
function. This is the sort of code extensions written in C will use to 
call moto functions passed to them. It is still undergoing development 
but you can get an idea how this might work from the C code for the new 
extension method Vector::each(void(Object)) :

void
vec_each(Vector *p, Function* f){
	int i;
	for (i=0;i<p->size;i++){
		f->flags & F_INTERPRETED ?
			ifunc_vcall(f,"O", p->elements[i]) :
			((void(*)(void*))f->fn)( p->elements[i]) ;
	}
}

There are however other issues with this idea too since most other 
stages execute prior to when we would like interpretation / page 
execution to take place.

Re: New syntax

>
> SetHandler would appear outside the "<XXXLocation>" tags either 
> enclosed in
> "<Location>" or "<Directory>" tags or as a server global. Whatever the
> module doesn't handle it will simply return "DECLINED" for and Apache 
> will
> skip it.
>
>
> <Location /myloc>
>    SetHandler mymodule
>
>    <XXXLocation /mysubloc>
>        ...
>    </XXXLocation>
> </Location>

The block style syntax is very interesting to me because it does have 
the potential to cut down the amount of 'stuff' written in the 
httpd.conf file.

First off, I wonder if <XXXLocation> is really the directive name we 
want. Since it already needs to be nested in a Location or Directory 
block (for SetHandler) I don't know if there's value in letting users 
specify a secondary prefix. I wonder if instead something like 
<XXXOptions> makes more sense. It would take no arguments of its own 
but every directive inside of it would be treated as if it were 
preceded by XXXOption.

It could also be offered as an alternative to

XXXOption <config var name> <config var option>

syntax without replacing it thus giving us backwards compatibility.

-Dave

On Friday, February 21, 2003, at 07:15  PM, Shay Harding wrote:

>> -----Original Message-----
>> From: David Hakim [mailto:dhakim-Gkm/TONP9n1Wk0Htik3J/[email protected]]
>> Sent: Friday, February 21, 2003 4:47 PM
>> To: Shay Harding
>> Cc: Moto Devel
>> Subject: Re: [moto-devel] 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 only stage that truly performs output is the content handler 
> (current
> default for moto now). If I write an access handler module in Moto 
> (which I
> already have) I can then, via Apache access handler phase, return
> "FORBIDDEN" and Apache will handle it from there and return a "401" 
> (or is
> it 403?) error page. If everything went well I return "OK" and Apache 
> keeps
> on processing.
>
>>> 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 ?
>
> The only directive is "<XXXLocation ...>". The moto module registers to
> handle this directive. Apache actually never sees anything past that 
> since
> the directive is specified as "<XXXLocation" so it eats it all until 
> the
> module itself breaks when it sees "</XXXLocation>".
>
> Then in the "setOption" function we pull out each line inside the 
> directive
> and process it using the same "ap_" functions Apache uses to process
> httpd.conf.
>
> I already have the above working in my moto devel local directory. The
> "Location" is still set using the value of "<XXXLocation>" as it 
> currently
> is doing.
>
>>> 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 ?
>
>
> SetHandler would appear outside the "<XXXLocation>" tags either 
> enclosed in
> "<Location>" or "<Directory>" tags or as a server global. Whatever the
> module doesn't handle it will simply return "DECLINED" for and Apache 
> will
> skip it.
>
>
> <Location /myloc>
>    SetHandler mymodule
>
>    <XXXLocation /mysubloc>
>        ...
>    </XXXLocation>
> </Location>
>
>
>>
>>>
>>> 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.
>
> The interpreted version would be more complex and basically a lot like
> mod_perl which creates a Perl interpreter to parse the modules. The
> "executeTemplate()" function seemed to be doing something similar here.
>
>
>> 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
>
>
> I think the compiled moto modules are the exact tool for the job as 
> they are
> basically C Apache modules just as if you'd write them in C. 
> Interpreted
> Apache modules really don't need to be added except to parallel 
> mod_perl
> which is used a lot. It's so easy to take the moto files and compile 
> them
> that the *need* for interpreted ones is lessened. The *need* for 
> mod_perl is
> evident since you really can't compile Perl code (well you can but 
> it's not
> really good code :)).
>
>
>
> 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
>
>
>