Apache configuration path

["David N. Welton" <da...@dedasys.com>]

Damon Courtney <da...@your.unreality.com> writes:

[ cc'ed to the rivet list, in case anyone else is listening/curious,
and so it's archived ]

> > Well, as long as you get the skeleton in there with your basic
> > ideas for how it should work, I might have some time to fill it
> > out.

>     Ok, so lemme' ask a couple of questions about Apache
> implementations.  When a page is called, what exactly happens if
> it's passed to our module?  Does Apache call the config merge
> command each time a page is loaded?

I don't think so, although in the case of .htaccess, I guess it might
have to?

> I'm not exactly clear on a lot of this stuff.

Unfortunately, it's not my strong suite either, but I have enough of a
handle on it that I think I can make it work.  I will also try and
write some test cases to automate checking, so that we can lock in a
correct behavior and not accidentally mess it up.

> I have the skeleton in place and everything compiles well.  I
> cleaned up a couple of warnings and cleaned up function definitions
> to make them all uniform and easy to find.

Yes, it compiles nicer and looks better - thanks!

>     Basically, I'm taking the functionality that was already there,
> but I'm also adding the functionality that NWS used to have.  Which
> is to say that every RivetConf command will set a varible in the
> respective array with the values specified in Apache.  This makes it
> really nice and easy to learn about the directives given to Apache
> from within the Tcl code.  So, if you do:

> RivetServerConf UploadDirectory /tmp

>     We set RivetServerConf(UploadDirectory) to /tmp.  This means
> that a programmer can actually learn this information later on down
> the line, or even reset it mid-stream.  I eventually wanna' re-write
> a lot of the C code as Tcl code and make it more like NWS was in
> some respects.

Sounds good - although it would be cool to make it so that as little
as possibe Tcl overhead is executed per request.

>     Almost all of NWS's work was done in Tcl code.  This made it
> really easy to go back through and make changes to your webserver
> without ever having to recompile the code.  For example: there was a
> routine which would setup each safe interpreter after it was
> created.  So, in C, we really would just eval setup_safe_interp with
> a few arguments, and Tcl did the work.  It's actually quite nice.

But you had to do this for each request, right?  That's slow!

> I'm thinking we can do the same with creating the namespaces and
> such.  Instead of doing a call to Tcl_Eval to create a namespace, we
> just Eval like "::rivet::setup_request_namespace" or something.

Actually, I've been trying to get the core guys to include this
functionality in tcl.h (it already exists internally) - so that the
whole thing is doable in C!  Although unfortunately, even after it
happens, I wouldn't want to use it untill whatever Tcl version that
may be becomes relatively widespread.

In mod_dtcl, come to think of it, it *is* possible to have a before
and after script.  Maybe to make things more uniform, we could have
those default to being the namespace setup and teardown.

Then we could also change the default behaviour, or add something like

BeforeScriptAdd "blah blah blah"

which tacks it onto the front, instead of overwriting it.

Just some quick thinking/brainstorming.

>     It'll all come together later.  Right now, the base is in place,
> I think.  Lemme' know what you know about Apache's config stuff, and
> I'll commit some code shortly so that maybe you can take it to the
> next level.  I think you have a far better understanding of Apache
> modules than I do.

Taken from mod_example, in the Apache sources:

{
    STANDARD_MODULE_STUFF,
    example_init,               /* module initializer */
    example_create_dir_config,  /* per-directory config creator */
    example_merge_dir_config,   /* dir config merger */
    example_create_server_config,       /* server config creator */
    example_merge_server_config,        /* server config merger */
    example_cmds,               /* command table */
    example_handlers,           /* [9] list of handlers */
    example_translate_handler,  /* [2] filename-to-URI translation */
    example_check_user_id,      /* [5] check/validate user_id */
    example_auth_checker,       /* [6] check user_id is valid *here* */
    example_access_checker,     /* [4] check access by host address */
    example_type_checker,       /* [7] MIME type checker/setter */
    example_fixer_upper,        /* [8] fixups */
    example_logger,             /* [10] logger */
#if MODULE_MAGIC_NUMBER >= 19970103
    example_header_parser,      /* [3] header parser */
#endif
#if MODULE_MAGIC_NUMBER >= 19970719
    example_child_init,         /* process initializer */
#endif
#if MODULE_MAGIC_NUMBER >= 19970728
    example_child_exit,         /* process exit/cleanup */
#endif
#if MODULE_MAGIC_NUMBER >= 19970902
    example_post_read_request   /* [1] post read_request handling */
#endif
};

Aside from the numbered ones, what happens at init time is actually
that the config creaters are run *first*, and then the example_init
and _child_init stuff is run.  Otherwise, we wouldn't be able to run
rivet_global_init_script at the server init time.

The merge stuff is what I don't have a tight handle on.  What I
*think* it is supposed to do is resolve conflicts when you have the
same config in a directory, and globally...

> > Speaking of Rivet, I discovered that there was a 'Rivet' project,
> > which was an effort to make a Tcl-less Tk.  I couldn't find any
> > current links, so I guess we can just consider another namespace
> > to stomp out:-) Actually, it might be a good idea to call it
> > Apache Rivet in any case, to 1) get the name recognition, and 2)
> > not totally stomp on the other projects in that namespace.

>     I don't mind calling it "Apache Rivet," or something similar.  I
> think we can benefit a lot from publicizing Apache, and I really
> don't have a care to make this stuff work under like Netscape or IIS
> or anything.  I'm more interested in making a really solid Apache
> product.  And I never use anything but Apache anyway. 0-]

Ok, although I guess that publicizing it can wait untill we actually
have something working.  Although I think that maybe by organizing
tcl.apache.org better, we could direct people interested in hacking
towards Rivet, and point others towards the stable projects.

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
     Personal: http://www.efn.org/~davidw/