Hi, Cool! Nice updates :)
On the version # question a few days back, I agree this is 4.x update. For a 5.x release, in addition to what you listed below, I'd add: -- integrate SSL support directly (comm driver, api's) -- integrate the comm drivers -- figure out some better build environment for windows -- ensure 64bit works everywhere -- finally re-factor the Tcl management -- make aolserver really just a loaded Tcl module The last two would be disruptive but interesting or maybe just dumb on closer inspection. Basically, aolserver could use the ns_itcl stuff along with Tcl package to better leverage existing extensions. As a module overall, the basic startup and event loop stuff could be exposed as commands instead of special case startup code in a custom binary. I think that could get aolserver/tcl closer to command-line PHP type flexibility which enables, e.g., "crush" in drupal. May be too much effort but something to explore. -Jim On Oct 19, 2011, at 1:45 AM, Jeff Rogers wrote: > 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 another new filter, "pre-write" which runs after content has been > returned but before it has been sent over the network. To make this useful, > there is a new method to ns_conn to examine and set the response content that > is about to be sent. This could be useful for implementing something like > apache's mod_pagespeed, which rewrites content to do things like merge > javascript and css files to reduce external requests, or just strip > extraneous whitespace from a page. > > - 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. > > Cheers, > -J > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <lists...@listserv.aol.com> with the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: > field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <lists...@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
