|
Boost : |
From: Darren Garvey (lists.drrngrvy_at_[hidden])
Date: 2007-04-22 17:50:34
On 22/04/07, Martin Wille <mw8329_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk