RE: Apache config for compiled modules

> -----Original Message-----
> From: David Hakim [mailto:dhakim-Gkm/TONP9n1Wk0Htik3J/[email protected]] 
> Sent: Tuesday, February 25, 2003 11:06 AM
> To: Shay Harding
> Cc: [email protected]
> Subject: Re: [moto-devel] Apache config for compiled modules
>
> 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.

I agree that re-inventing the wheel is typically a waste of time but when I
mentioned "url-rewriting" I was referencing an Apache stage and not
functionality. The Apache module "mod_alias" operates at the url-rewriting
stage for instance.

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

This is true for all languages that access the Apache API. Apache 1.3x and
2x APIs are completely different although, as far as I know, 2x is backwards
compatible to run 1.3x modules.


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

Agreed. Adding this functionality in the interpreter would be much more
complex as you basically need a handler-wrapper for each stage of Apache's
request process within mod_moto.


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

This is fine if Moto's only intended purpose is to make web apps (homepages,
shopping carts, etc); HTML output with some database activity.

A perfect example of where I think Moto would shine is an Apache handler for
access control. Everything you need is already built into Moto (especially
the sharing of data between Apache processes via the Context stuff) and it
compiles down to C code for loading as a DSO. This means it could
potentially be a sellable product. There's a product called Iprotect
(http://www.visox.com/iprotect.html) that is basically the same thing I
wrote in 200 lines (or less) of Moto code.

Yes, the above can (and Visox did) be written in C, but it's a LOT easier to
write it in Moto then compile it down to C, a lot easier to debug and a lot
easier to maintain.

I don’t want to try and force Moto to do my bidding if it's end goal(s) is
not inline with what I need in a language. I like Moto because it compiles
to C and is easy to learn and work with. Bad thing is I'm not a web
developer and need much more than database access to accomplish routine
tasks. Currently I use Perl and C to accomplish these tasks. The two
problems I was hoping to solve with Moto are:

1) Perl cannot be compiled so is at the mercy of interpreter speed
     a. This may be a non-issue 2 years from now when Perl 6 is finally done
2) C development time is longer than an equal app in Perl (but much faster)



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

Well, my thinking here is that a Moto page for Apache handlers would be
specific to handling Apache tasks and not mixed with, say HTML code (unless
it's a content handler I suppose). The only reason I could see for
registering a function within a page was if you placed many handlers in the
same moto file (which is nice for convenience).

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

Well since all Moto handlers are content handlers, you can simply say in
global server context

SetHandler   XXXHandler

<XXXLocation /maindir/mymotofiles>
   CustomWhatever   20
   Session.Disable  TRUE
</XXXLocation>

so it has the same type of syntax as the native "<Location>" tag. This is no
different than:

SetHandler XXXHandler

<XXXOptions>
   Location /maindir/mymotofiles
   CustomWhatever   20
   Session.Disable  TRUE
</XXXOptions>


They would be processed the same way. I don't know... the "XXXOptions" just
seems redundant as everything completely depends on the "Location" so
"XXXLocation" just seemed to fit.


> 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


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