On Tuesday 08 February 2005 06:20, Bernd Eidenschink wrote: > * Having a 'real' config file with _all_ default values. > Maybe the current grep-thru-code way could somehow be simplified. >
Check my new, 'complete' config file: <http://rmadilo.com/m2/> starting at jnm.tcl Config file is broken into different files, based on branching/repeated sections. In the example case, I have three virtual servers: jnm, configtest and cf2, with jnm being the name of the 'main' or default server, although there isn't supposed to be a default. There are three nssock modules loaded and the three servers are spread among these, I have nsdb support shown, and threadpools, nscgi and a tcl module. The main config file is jnm.tcl here's the structure: /web/m2/jnm.tcl <-- main config /nsdb-jnm.tcl <-- main nsdb for the jnm server /nsdb-jnm-pg.tcl <-- postgres db pool config /nsdb-jnm-pool[1-3].tcl <-- symlinks to nsdb-jnm-pg.tcl /servers/jnm/config/ <-- config directory for jnm /servers/jnm/config/server.tcl <-- main server config for jnm /servers/jnm/config/nslog.tcl <-- access log module configuration /servers/jnm/config/nscgi.tcl <-- module named nscgi config /servers/jnm/config/threadpool-fast.tcl <-- threadpool named fast /servers/jnm/config/module-name.tcl <-- for other modules The scripts included try to be smart about loading virtual servers. First the config files for the server are read. If there are simple syntax errors, these are caught and the virtual server is removed from the list of servers. Next successful servers are added to ns/servers and mapped to the nssocks. If an nssock ends up with no virtual servers mapped, or the default virtual server for that sock had an error, the nssock is not added, otherwise the whole jnm server would fail to startup. Successful nssocks are read into the configuation file. It is easy to extend the functionality of this setup. Module maintainers can simply add a single file, containing all the config parameters (if one is needed). You just add the module name to the server.tcl file for the virtual server. NOTE: there is currently a bug in the virtual server loading. The nssock section must contain a defaultserver parameter, or the nssock, and the whole server fail to start (This is by design, and is correct). However, only the defaultserver of the last registered nssock is used. That is, one virtual server serves as the default virtual server for every nssock, even if there were never any maps to that virtual server in the nssockX/servers section. NOTE2: users of virtual servers running 4.0.8 or 4.0.9 should upgrade to 4.0.10, due to a DOS bug. If you need info, email me directly. > * Altering pageroot depending on HTTP host header Should require one new api call, oh, and why not allow threadpools to operate on this info as well? As a fast workaround, chechout ns_rewriteurl, you can map within the server pageroot. Although this sounds not that good, since the actual pageroot might look like: /pages/ /pages/vserver1/ /pages/vserver2/ etc. You can 'disable' the main, or non-matching host header by having a default mapping, i.e. you could never reach /pages/. > plus > dis-allowing any adp/tcl funcionality for these pageroots > on a file level (no interpretation) as an option > > * Server-wide shared variables > Maybe we can get AOL to release the PROXY support which has a 'specialized tclsh', probably requires all this and more. Although Rob Mayoff's threadpool module seems great, I believe the threads are clones of the server they run in, thus they could be fat. If virtual servers could communicate to each other (on a publish/subscribe basis), just about any smallish server could be used, but I suspect the PROXY module used by AOL has even more useful features??? > * Up-to-date patches for PHP (...) integration > > * Some kind of watchdog functionality > Actually only a built in module would work very well, and fast. Every solution I've seen is a true hack, which is why it needs to be in core. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
