On 5/14/2011 4:25 PM, Jeff Trawick wrote: >> * Not all MPMs are updated to set conn_rec::current_thread correctly. >> (Prefork, Worker, Event, Simple are updated). >> jim sez: Then we just ship with those... mark any others as >> experimental, pgollucci +1 jim >> + wrowe sez: no... Then we just don't ship those (see #1 above) >> + Is this still an issue, didn't jtrawick fix this? > > I don't think so ;) > > I just added it to my white board so that there's one person to beat > up on for a series of small, untested, changes to odd MPMs.
Thanks, I remembered activity on this and didn't remember if it was resolved. >> * The mod_session* modules need to be checked that their hooks respect >> the returning of int (HTTP status codes) and apr_status_t as appropriate, >> @@ -92,10 +95,26 @@ RELEASE SHOWSTOPPERS: >> modules that mix these 2 types... clean up is >> forthcoming but should not be considered a blocker, imo >> pgollucci: +1 jim >> - >> + wrowe asks: what's the API change required? >> + wrowe asks; why are we shipping this if it requires apr_ssl > > apr-util 1.next would be highly valuable to some of us for other > reasons. It remains to be seen if that fact will dislodge some time > :( No argument, but there are 1) minor quibbles with the apr-2 interface, and 2) some significant work to replace the original with the new interface, and not sure who has cycles to attack this in the near term. If it is fixed, re-adding mod_session during 2.4.x cycle would be relatively painless, no? >> + * INCLUDE mod_fcgid with 2.4.0, esp to help php users etc to enjoy >> + a painless event mpm experience. > > I'll probably be a distant observer on this one. I have concerns > about locking in compatibility constraints for the next N years (or, > causing confusion with a separate, unbundled fcgid which also works > with httpd 2.4), but it has been some time since I've been able to > devote any energy to fcgid, and until that changes I should just stay > out of the way. Well, we might have to work out most of the mod_fcgid code space clearly into the *private* domain. No 'public headers' for example, but just locking in the fastcgi behavior towards the client executables (with the caveat emptor that this is subject to bug fixing).
