On 22/04/07, Martin Wille <mw8329@yahoo.com.au> wrote:
No problem here. However, I do not want my code be limited to a single web server implementation, anyway; so mod_* isn't really something I usually consider for a web applications.
My understanding of mod_proxy_http was that it just redirects the HTTP request (after load-balancing/anti-throttling/adminstrating) to the program, rather than first translating it into a CGI request. It's one step back from having a standalone web program.
- how significant SCGI is (would anyone use it?);
Well, I use SCGI. However, if FastCGI and WSGI get supported then there's probably nobody who would insist on getting SCGI supported.
- non-CGI/FastCGI/SCGI/HTTP protocols that might be of interest;
WSGI.
Maybe, some people would like a tomcat-compatible connector.
Noted. Incidentally, I figured WSGI wasn't a protocol per-se, but a framework for handling multiple protocols?
- low-level design decisions
It would be great if multiprocess and multithreading designs would be supported, respectively.
Multithreading support will definitely be included, although I'm not sure about multiprocess (at least for the SoC timeline). It would also be great if not only basic HTTP authentication would get
supported.
Support for session management would be nice to have, but not essential. If such support exists then it would be nice if it would support cookieless session management.
I wonder how controversial this would be? I suppose it'd be quite simple to implement and easy to remove if it was a problem. Support for streaming could be interesting (not sure if that can
actually be done in the CGI world, though).
By streaming do you just mean C++ streams, or some other fandanglery? Support for i/o streaming is vital, I think. Cheers, Darren