I'm about to start using aolserver for the first time in many, many years, so your post is very encouraging, and the changes look good. Your "exposed the gzip flag to tcl scripts (ns_conn gzip)" item reminded me that I believe I had promised some code a while back on that...and I forgot to upload it...my apologies to those expecting it.
I'll grab the latest and greatest from SF and start messing around with your changes. Is SF the main repo for aolserver? What about the modules (specifically nspostgres)?
RE: TclX...can't that be loaded as an extension, so that those who still need it can load it?
Thanks for your effort. --brett
________________________________ From: Jeff Rogers <dvrsn@DIPH...> To: AOLSERVER@LIST... Sent: Tuesday, October 18, 2011 10:45 PM Subject: [AOLSERVER] recent updates
Hey all, me again.
For those of you who don't monitor the commits list I wanted to share a few changes I've recently made as well as a few I'm still thinking about.
- implemented native decoding of strings in ns_returnfile. This allows filenames that are not utf-8 to be passed, similar to tcl core functions.
- committed a long-outstanding patch to address a fastpath caching bug where incorrect file content could be delivered in a system when inodes are rapidly being reused. Added a new config option "cacheminage" to control this behavior.
- implemented a suggestion to re-run pre-auth and post-auth filters on internal redirects. As this could break assumptions in unusual situations, there is a config option "filterredirect" to disable it. Among other things, this addresses an issue in openacs that made it complicated to handle 404 errors. Also fixed a server crash when there is an error in the configured error page.
- added flags to insert a filter at the beginning of the list of registered filters instead of only at the end, and to order filters by priority.
- exposed the gzip flag to tcl scripts (ns_conn gzip)
- added a tuning knob "maxaccept" to let the driver accept more than one connection per spin. The SF RFE for this referenced a paper that found this type of change could improve performance and reduce dropped connections under load; I unfortunately don't have a network capable of simulating enough load to stress this so I cannot claim any measured improvement.
I also have a few other ideas I haven't gotten around to adding (or even necessarily thinking through completely) yet:
- removing encoding and gzip compression from the normal response writing codepath (Ns_ConnFlush) and making them into pre-write filters.
- adding an api to name C-coded filters and handler procs such that they could be used by the tcl ns_register_filter/ns_register_proc commands. This could eliminate a few special-purpose commands that do this same thing for particular operations (ns_register_fastpath and ns_register_filter_shortcut).
- add support for chunked encoding for requests, digest authentication, and Expect: 100-continue. I've heard that these are already supported in NaviServer, so this may be a fairly simple cut&paste enhancement.
- replace c-coded versions of many file operations with equivalent tcl-coded versions. Many of these functions (e.g., ns_mkdir, ns_cp) come from before tcl had equivalent functionality, but tcl now has that functionality, and it's better (native decoding).
- replace ns_share with tcl version built around nsv, if not eliminating it entirely.
- remove other really old code like tclx keylist support. I honestly don't know if this is still being used, perhaps it could be kept around in a "nscompat" module along with other things like ns_var and ns_share). I'm a bit reluctant to break compatibility without an easy switch to un-break it.
- make content sending event based, by pushing it back to the driver thread, a task thread, or a completely new writer thread, rather than blocking a conn thread if the content is big and the network is slow. There is support for doing this at the tcl level, but it would be nice to have it implicitly happen everywhere.
- let queue-waits be set up from a conn thread and the conn re-queued in the driver thread. This would let you do database operations before making network calls and still wait for those calls to complete without tying up conn threads. This would mean a rather esoteric coding style but I think it would make for a really powerful mashup engine.
Some of these are pretty disruptive (especially the last two), and introducing incompatibilities (even ones with an easy off switch) is not something to be taken lightly; does anyone else think a new 4.5.2 release with the recent bugfixes and non-disruptive new features could be done, and then slightly disruptive stuff (i.e., moving c-coded commands to tcl) could be targeted at 4.6?
Naturally, I'm also interested in any feedback on anything I've done or suggested also.