[soc07][cgi] RFC: use-cases/scope
Hello all, In preparation for working on a cgi library for the Summer of Code (proposal: cgi.sf.net/proposal.html), I'd like to collect a list of use-cases for such a library. The purpose of this discussion isn't to decide what goes into the library (the scope will be limited to CGI, FastCGI and possibly SCGI backends) - although please don't let that censor your thoughts - but to ensure the library is structured in such a way to allow the widest potential for expansion. Of particular interest are thoughts about: - CGI vs. HTTP: if the library worked with (for example) mod_proxy_http, would the 'limitation' of only providing CGI variables be an acceptable compromise for the sake of portability across protocols? - how significant SCGI is (would anyone use it?); - non-CGI/FastCGI/SCGI/HTTP protocols that might be of interest; - low-level design decisions There's going to be a lot of work put into this library over the Summer, so now is the best time to impress your ideas on us, before they're 'set in stone', so to speak. Regards, Darren
Hi, What I would like to see if possible: 1. Session/cookie management 2. Easy way to generate the HTML DOM tree 3. Possibility of running as an apache module Here are some to compare to: http://www.gnu.org/software/cgicc/cgicc.html http://www.ii.uib.no/~stig/Projects/Cgipp/ Notice the cout << html() to output opening and closing tags etc. Also somewhat of interest: http://www.tntnet.org/ http://sourceforge.net/projects/mod-c Thanks Shams -- "Darren Garvey" <lists.drrngrvy@googlemail.com> wrote in message news:1be3e4b20704212220h63531907ld95fa9616d26d8cb@mail.gmail.com...
Hello all,
In preparation for working on a cgi library for the Summer of Code (proposal: cgi.sf.net/proposal.html), I'd like to collect a list of use-cases for such a library.
The purpose of this discussion isn't to decide what goes into the library (the scope will be limited to CGI, FastCGI and possibly SCGI backends) - although please don't let that censor your thoughts - but to ensure the library is structured in such a way to allow the widest potential for expansion.
Of particular interest are thoughts about: - CGI vs. HTTP: if the library worked with (for example) mod_proxy_http, would the 'limitation' of only providing CGI variables be an acceptable compromise for the sake of portability across protocols? - how significant SCGI is (would anyone use it?); - non-CGI/FastCGI/SCGI/HTTP protocols that might be of interest; - low-level design decisions
There's going to be a lot of work put into this library over the Summer, so now is the best time to impress your ideas on us, before they're 'set in stone', so to speak.
Regards, Darren _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Shams wrote:
2. Easy way to generate the HTML DOM tree
This seems to be a commonly requested feature form cgi libraries but is it really that necessary? It seems to me that it just encourages bad habits, i.e. mixing logic and presentation. Shouldn't we instead focus on providing a convenient template system a la ctemplate but with a more appropriate API? Steven Siloti
Steven Siloti wrote:
Shams wrote:
2. Easy way to generate the HTML DOM tree
This seems to be a commonly requested feature form cgi libraries but is it really that necessary?
No, it's not, IMHO. "CGI" is about a protocol (or about several protocols if FCGI, SCGI, WSGI, etc get supported, too), "HTML" is just one of many document formats delivered over that protocol. It really makes no sense to couple those two tightly. Additionally, it's more than what I would expect to be done during a single SoC session. It seems to me that it just encourages bad
habits, i.e. mixing logic and presentation.
Agreed. Shouldn't we instead focus
on providing a convenient template system a la ctemplate but with a more appropriate API?
This makes more sense than supporting a single document format. However, I think it's also beyond the scope of a CGI library. A template engine could be useful in non-web applications as well; so it should not get coupled with a protocol engine, either. Regards, m
Hi Martin, On 22/04/07, Martin Wille <mw8329@yahoo.com.au> wrote:
Steven Siloti wrote:
Shams wrote:
2. Easy way to generate the HTML DOM tree
This seems to be a commonly requested feature form cgi libraries but is it really that necessary?
No, it's not, IMHO. "CGI" is about a protocol (or about several protocols if FCGI, SCGI, WSGI, etc get supported, too), "HTML" is just one of many document formats delivered over that protocol. It really makes no sense to couple those two tightly.
Additionally, it's more than what I would expect to be done during a single SoC session.
I agree. I've played with having html helper classes with CGI libraries in the past, but I don't think including it suits either Boost or C++. It seems to me that it just encourages bad
habits, i.e. mixing logic and presentation.
Agreed.
Ok. Shouldn't we instead focus
on providing a convenient template system a la ctemplate but with a more
appropriate API?
This makes more sense than supporting a single document format. However, I think it's also beyond the scope of a CGI library. A template engine could be useful in non-web applications as well; so it should not get coupled with a protocol engine, either.
Jeff Garland sent me a link ( http://tinyurl.com/6v5vx ) which mentioned a need for html/xml/soap stream formatting libraries too. The best I can do for now is to make the library c++-stream and Boost.Iostreams compatible, and wait for the other libraries to come around. Thanks for the comments, Darren
Darren Garvey wrote:
Hi Martin,
This makes more sense than supporting a single document format. However, I think it's also beyond the scope of a CGI library. A template engine could be useful in non-web applications as well; so it should not get coupled with a protocol engine, either.
Jeff Garland sent me a link ( http://tinyurl.com/6v5vx ) which mentioned a need for html/xml/soap stream formatting libraries too. The best I can do for now is to make the library c++-stream and Boost.Iostreams compatible, and wait for the other libraries to come around.
Just to clarify my point....I was suggesting that *I* wanted to see a cgi library and a separate libs for formatting html/xml/soap data. At the time I sent the link I was simply pointing out that some of us would like to see a C++ CGI library as one of several libraries that would support web development. Personally I don't see any reason why the SoC project has to do anything with streams for output -- stringstream is able to do all that's needed for now. That said, I'd like to see the cgi library provide support for cookie and session handling. That seems more in scope to me than worrying about html output like perl::cgi does. Oh, and I'd agree that support for a file upload is a good use case that should be supported. Jeff
Hi, Yes I forgot to mention that and IF possible I'd rather go with a templating system but as a separate library or project. Here is an example of a c++ template language from Google. http://goog-ctemplate.sourceforge.net/ Thanks Shams -- "Steven Siloti" <ssiloti@gmail.com> wrote in message news:462B9A98.2090502@gmail.com...
Shams wrote:
2. Easy way to generate the HTML DOM tree
This seems to be a commonly requested feature form cgi libraries but is it really that necessary? It seems to me that it just encourages bad habits, i.e. mixing logic and presentation. Shouldn't we instead focus on providing a convenient template system a la ctemplate but with a more appropriate API?
Steven Siloti _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, The project should make it clear how it supports different needs and it allows a basic to advanced path: CGI: support to allow any c++ program to output results to a browser (typical cases are to output a html or an image via a web server) FCGI,SCGI: support to build a server deamon that interfaces to a web server via tcp sockets (e.g. apache front-end via mod_fcgi to a custom c++ daemon) Web server: support to build a basic web server tied to a c++ application but with the web server also supporting CGI/FCGI on the server-side (e.g. improved asio http server) Advanced - simulations, debugging: support to build a web server thread that can be used to debug the application or to query the status of a long running application via a web browser<http://code.google.com/p/gperftools-httpd/>(see http://code.google.com/p/gperftools-httpd/) As for the other features (sessions, templates, ..) I think the first priority should be sessions but probably this is already too much for this project. I am glad this project got accepted and also that Chris is mentoring it, as there is a lot of related work already in asio examples. regards, jose On 4/23/07, Shams <shams@orcon.net.nz> wrote:
Hi,
Yes I forgot to mention that and IF possible I'd rather go with a templating system but as a separate library or project.
Here is an example of a c++ template language from Google. http://goog-ctemplate.sourceforge.net/
Thanks Shams
--
"Steven Siloti" <ssiloti@gmail.com> wrote in message news:462B9A98.2090502@gmail.com...
Shams wrote:
2. Easy way to generate the HTML DOM tree
This seems to be a commonly requested feature form cgi libraries but is it really that necessary? It seems to me that it just encourages bad habits, i.e. mixing logic and presentation. Shouldn't we instead focus on providing a convenient template system a la ctemplate but with a more appropriate API?
Steven Siloti _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I forgot to ask, which cases below are you targeting ? (i thought 1, 2, 3) On 4/23/07, Jose <jmalv04@gmail.com> wrote:
Hi,
The project should make it clear how it supports different needs and it allows a basic to advanced path:
CGI: support to allow any c++ program to output results to a browser (typical cases are to output a html or an image via a web server)
FCGI,SCGI: support to build a server deamon that interfaces to a web server via tcp sockets (e.g. apache front-end via mod_fcgi to a custom c++ daemon)
Web server: support to build a basic web server tied to a c++ application but with the web server also supporting CGI/FCGI on the server-side ( e.g. improved asio http server)
Advanced - simulations, debugging: support to build a web server thread that can be used to debug the application or to query the status of a long running application via a web browser <http://code.google.com/p/gperftools-httpd/> (see http://code.google.com/p/gperftools-httpd/)
As for the other features (sessions, templates, ..) I think the first priority should be sessions but probably this is already too much for this project.
I am glad this project got accepted and also that Chris is mentoring it, as there is a lot of related work already in asio examples.
regards, jose On 4/23/07, Shams <shams@orcon.net.nz> wrote:
Hi,
Yes I forgot to mention that and IF possible I'd rather go with a templating system but as a separate library or project.
Here is an example of a c++ template language from Google. http://goog-ctemplate.sourceforge.net/
Thanks Shams
--
"Steven Siloti" <ssiloti@gmail.com> wrote in message news:462B9A98.2090502@gmail.com ...
Shams wrote:
2. Easy way to generate the HTML DOM tree
This seems to be a commonly requested feature form cgi libraries but is it really that necessary? It seems to me that it just encourages bad habits, i.e. mixing logic and presentation. Shouldn't we instead focus on providing a convenient template system a la ctemplate but with a more appropriate API?
Steven Siloti _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Jose, On 25/04/07, Jose <jmalv04@gmail.com> wrote:
I forgot to ask, which cases below are you targeting ? (i thought 1, 2, 3)
If the 1,2,3 implies the three emails, I'll just clarify that _everything_ to do with 'output formatting' is excluded from the library. Provisionally, the only output ability will be via operator<<, write(), write_file() - for a response that is a file - and print_file() - for a response that _contains_ a file as well as other data. (feel free to disagree) On 4/23/07, Jose <jmalv04@gmail.com> wrote:
Hi,
The project should make it clear how it supports different needs and it allows a basic to advanced path:
CGI: support to allow any c++ program to output results to a browser (typical cases are to output a html or an image via a web server)
FCGI,SCGI: support to build a server deamon that interfaces to a web server via tcp sockets (e.g. apache front-end via mod_fcgi to a custom
c++
daemon)
This is the main focus of the SoC project.
Web server: support to build a basic web server tied to a c++ application
but with the web server also supporting CGI/FCGI on the server-side ( e.g. improved asio http server)
This would, of course, be nice. However I'm not sure how much of a mammoth task it'd be. Support for general HTTP would come first, that would be the first step to a full-blown server. Obviously, I don't have any delusions about this getting done any time soon (or even by me at all - someone might beat me to it).
Advanced - simulations, debugging: support to build a web server thread
that can be used to debug the application or to query the status of a long running application via a web browser <http://code.google.com/p/gperftools-httpd/> (see http://code.google.com/p/gperftools-httpd/)
Debugging would be very handy although, again, this isn't planned for this summer. Being able to query the status of the program would be possible using the planned structure: stuff like the number of requests handled, request queue size, etc. would all be accessible via the 'service' class. However, the ability to do it via a web browser wouldn't be part of the library. One way to do this would be to use asio to have the main program (a FastCGI responder, for instance) to set up a listening socket, which could take queries and translate them into actions on the 'service' object, returning the result. To make this info accessible via a browser, all you'd need to do is set up a program that accepts cgi requests, connects to the listening socket on the main program, and acts as a gateway for the requests/responses. [snip] Cheers, Darren
On 4/25/07, Darren Garvey <lists.drrngrvy@googlemail.com> wrote:
Hi Jose,
On 25/04/07, Jose <jmalv04@gmail.com> wrote:
I forgot to ask, which cases below are you targeting ? (i thought 1, 2, 3)
If the 1,2,3 implies the three emails, I'll just clarify that _everything_ to do with 'output formatting' is excluded from the library. Provisionally, the only output ability will be via operator<<, write(), write_file() - for a response that is a file - and print_file() - for a response that _contains_ a file as well as other data. (feel free to disagree)
The numbers refer to the use cases: 1) CGI output support 2) FCGI deamon support (and optionally FCGI on the c++ web server side to interface to the FCGI daemon) 3) an improved asio http server that supports CGI pages (this would be very useful) 4) advanced applications, like debugging On 4/23/07, Jose <jmalv04@gmail.com> wrote:
Hi,
The project should make it clear how it supports different needs and
it
allows a basic to advanced path:
CGI: support to allow any c++ program to output results to a browser (typical cases are to output a html or an image via a web server)
FCGI,SCGI: support to build a server deamon that interfaces to a web server via tcp sockets (e.g. apache front-end via mod_fcgi to a custom c++ daemon)
This is the main focus of the SoC project.
Web server: support to build a basic web server tied to a c++ application
but with the web server also supporting CGI/FCGI on the server-side ( e.g. improved asio http server)
This would, of course, be nice. However I'm not sure how much of a mammoth task it'd be. Support for general HTTP would come first, that would be the first step to a full-blown server. Obviously, I don't have any delusions about this getting done any time soon (or even by me at all - someone might beat me to it).
Basic HTTP 1.0 is already in the example. What would be nice is to expand the server so that it can run CGI scripts.
Advanced - simulations, debugging: support to build a web server thread
that can be used to debug the application or to query the status of a long running application via a web browser <http://code.google.com/p/gperftools-httpd/> (see http://code.google.com/p/gperftools-httpd/)
Debugging would be very handy although, again, this isn't planned for this summer. Being able to query the status of the program would be possible using the planned structure: stuff like the number of requests handled, request queue size, etc. would all be accessible via the 'service' class. However, the ability to do it via a web browser wouldn't be part of the library.
One way to do this would be to use asio to have the main program (a FastCGI responder, for instance) to set up a listening socket, which could take queries and translate them into actions on the 'service' object, returning the result. To make this info accessible via a browser, all you'd need to do is set up a program that accepts cgi requests, connects to the listening socket on the main program, and acts as a gateway for the requests/responses.
[snip]
Cheers, Darren _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 25/04/07, Jose <jmalv04@gmail.com> wrote:
The numbers refer to the use cases:
1) CGI output support 2) FCGI deamon support
Both included. (and optionally FCGI on the c++ web server side to
interface to the FCGI daemon)
My guess is that if this is ever done, it won't appear for a long time. 3) an improved asio http server that supports CGI pages (this would be very
useful)
Adding http support to the library is a possibility, and has been discussed before. It's _not_ part of the SoC project though: at best it'll be added later, assuming all goes well. That said, http support isn't likely to be safe for use as a public 'server' at any point: that's a huge task and one probably far beyond the realm of any single library. 4) advanced applications, like debugging
Not included, but see my previous mail. Darren
I'd fall back to using apache or lighthttpd anytime. However module support would be cool. I mean design the library in such a way that it could run as a standalone cgi program or as an apache module like php. Thanks Shams -- "Darren Garvey" <lists.drrngrvy@googlemail.com> wrote in message news:1be3e4b20704251546l79e1036u99fb51c9f67274d0@mail.gmail.com...
On 25/04/07, Jose <jmalv04@gmail.com> wrote:
The numbers refer to the use cases:
1) CGI output support 2) FCGI deamon support
Both included.
(and optionally FCGI on the c++ web server side to
interface to the FCGI daemon)
My guess is that if this is ever done, it won't appear for a long time.
3) an improved asio http server that supports CGI pages (this would be very
useful)
Adding http support to the library is a possibility, and has been discussed before. It's _not_ part of the SoC project though: at best it'll be added later, assuming all goes well. That said, http support isn't likely to be safe for use as a public 'server' at any point: that's a huge task and one probably far beyond the realm of any single library.
4) advanced applications, like debugging
Not included, but see my previous mail.
Darren _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 4/26/07, Darren Garvey <lists.drrngrvy@googlemail.com> wrote:
3) an improved asio http server that supports CGI pages (this would be very
useful)
Adding http support to the library is a possibility, and has been discussed before. It's _not_ part of the SoC project though: at best it'll be added later, assuming all goes well. That said, http support isn't likely to be safe for use as a public 'server' at any point: that's a huge task and one probably far beyond the realm of any single library.
I would see this not as part of http support but CGI support on the server-side. This is very useful when you have your own server (like asio example) and you want to keep the CGI scripts that are not performance-sensitive. Not sure what this feature implies and maybe not possible if asio doesn't support pipes, right ? thanks
Shams wrote:
Hi,
Yes I forgot to mention that and IF possible I'd rather go with a templating system but as a separate library or project.
Here is an example of a c++ template language from Google. http://goog-ctemplate.sourceforge.net/
You might have missed our earlier discussion of this project: http://lists.boost.org/Archives/boost/2007/04/119657.php It's interesting to be sure, but it's interfaces could likely be improved...things like the ambiguous char* interfaces. Anyway, I don't agree with Mathias that it's as basic as it first appears. In fact, I think it holds to the principles espoused in this paper by Terrence Parr (inventor of antlr parser generator and StringTemplate template engine) http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf which I suspect is mostly a good evaluation of how to build a minimal but sufficient templating system. Anyway, I brought it up simply as evidence that the 'wisdom' that C++ isn't useful for web programming is flawed -- but ctemplate is licensed well and targeted at html, so it's certainly possible to use for demonstration purposes in the SoC project. It could help keep the focus of the CGI library away from building html responses which I hope we all agree is out of scope. Jeff
Hello Jeff, On 23/04/07, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
[snip good link]
Anyway, I brought it up simply as evidence that the 'wisdom' that C++ isn't useful for web programming is flawed -- but ctemplate is licensed well and targeted at html, so it's certainly possible to use for demonstration purposes in the SoC project. It could help keep the focus of the CGI library away from building html responses which I hope we all agree is out of scope.
I think it's unanimous, which is handy. I'll have to make a point in the 'design decisions' about this. Darren
Hi Shams, On 22/04/07, Shams <shams@orcon.net.nz> wrote:
Hi,
What I would like to see if possible: 1. Session/cookie management
Session management isn't something I was planning on adding, although I suppose it's reasonable to expect a CGI lib to do basic session management. Hmm, thanks for that! 2. Easy way to generate the HTML DOM tree As per below, I purposely excluded this from my SoC proposal simply because it's more sensible (IMO) to implement this on top of the cgi library. 3. Possibility of running as an apache module This isn't the first time this has been suggested. This would definitely be beyond SoC-scope, but it's something that would be nice to be able to do. It would be a big job to make it work as a module, so I'll just brush over this for now, if that's ok. :) Here are some to compare to:
http://www.gnu.org/software/cgicc/cgicc.html http://www.ii.uib.no/~stig/Projects/Cgipp/
Notice the cout << html() to output opening and closing tags etc.
Also somewhat of interest: http://www.tntnet.org/ http://sourceforge.net/projects/mod-c
Thanks for the links. Regards, Darren
Hello, Darren Garvey wrote:
- low-level design decisions
If possible, I'd like to see some support for embedded devices. Due to the computing power/memory constraints, there are a few things that are important in such a setting. First, memory fragmentation is a real problem. Apache spawns new child processes with unfragmented memory maps every n requests to avoid this, however you can only do this with an MMU. Since a lot of embedded devices have none, people use pooled allocators and group related allocations together in order to minimize the impact; ideally, there'd be a way for allocations made while serving one request to use a specific allocator instance (the default, of course, being the standard new/delete allocator). Related to this: it is quite unlikely that it is possible to allocate large buffers, so allowing a way to access form form elements as a stream (before the incoming data is fully processed) would be good. One of *the* major use cases of form processing is firmware upload. The CGI needs to be able to accept these files (which can be as large as half the available system memory, so loading them into RAM is not an option), and also be able to recover if an invalid file is submitted (i.e. the CGI should be able to inspect the data as it is uploaded, and there should be an option to ignore the remainder of the file upload in case of an error so an appropriate error message can be returned). Speaking of error messages, the header output needs to be delayed until after processing obviously, and there needs to be a way to simply stream a file as a response. Ideally, it all would integrate with boost's iostreams and/or asio to allow the user code to reuse as much code as possible. Simon
Hello Simon, thanks for the advice. On 22/04/07, Simon Richter <Simon.Richter@hogyros.de> wrote:
Hello,
Darren Garvey wrote:
- low-level design decisions
If possible, I'd like to see some support for embedded devices.
I couldn't think of why you'd use an embedded device for a CGI program. I've just been reading up though, I get it now. Due to the computing power/memory constraints, there are a few things
that are important in such a setting.
First, memory fragmentation is a real problem. Apache spawns new child processes with unfragmented memory maps every n requests to avoid this, however you can only do this with an MMU. Since a lot of embedded devices have none, people use pooled allocators and group related allocations together in order to minimize the impact; ideally, there'd be a way for allocations made while serving one request to use a specific allocator instance (the default, of course, being the standard new/delete allocator).
This hadn't crossed my mind. Oops. Just to clarify, when you say: '...there'd be a way for allocations made while serving one request to use a specific allocator instance', are you talking about providing such an allocator for _users_ of the library, or are you talking just about handling memory allocation internally? Related to this: it is quite unlikely that it is possible to allocate
large buffers, so allowing a way to access form form elements as a stream (before the incoming data is fully processed) would be good. One of *the* major use cases of form processing is firmware upload. The CGI needs to be able to accept these files (which can be as large as half the available system memory, so loading them into RAM is not an option), and also be able to recover if an invalid file is submitted (i.e. the CGI should be able to inspect the data as it is uploaded, and there should be an option to ignore the remainder of the file upload in case of an error so an appropriate error message can be returned).
Point taken. The ability to handle file uploads was the reason I rolled my own basic-CGI lib, a couple of years ago. It's a bit trickier with FastCGI, but not significantly so. Speaking of error messages, the header output needs to be delayed until
after processing obviously, and there needs to be a way to simply stream a file as a response.
Ideally, it all would integrate with boost's iostreams and/or asio to allow the user code to reuse as much code as possible.
Integration with Boost.Iostreams is something I've yet to get working (but I do intend to). My mentor for the SoC is Chris Kohlhoff, so integration with asio isn't a choice (actually, asio's essential to the FastCGI stuff). ;-) Regards, Darren
Darren, Darren Garvey wrote:
First, memory fragmentation is a real problem. Apache spawns new child processes with unfragmented memory maps every n requests to avoid this, however you can only do this with an MMU. Since a lot of embedded devices have none, people use pooled allocators and group related allocations together in order to minimize the impact; ideally, there'd be a way for allocations made while serving one request to use a specific allocator instance (the default, of course, being the standard new/delete allocator).
This hadn't crossed my mind. Oops. Just to clarify, when you say: '...there'd be a way for allocations made while serving one request to use a specific allocator instance', are you talking about providing such an allocator for _users_ of the library, or are you talking just about handling memory allocation internally?
The user of the library would provide the allocator, and the library would "call back" into the user for memory allocation and deallocation. The allocator would be per-request ideally, so that when we are using an extension that allows handling of multiple simultaneous requests in the same process (or fold the gateway code into the HTTPd, as is done on some devices), we can keep the allocations made for each request separate. Simon
Hi Simon, On 25/04/07, Simon Richter <Simon.Richter@hogyros.de> wrote:
This hadn't crossed my mind. Oops. Just to clarify, when you say: '...there'd be a way for allocations made while serving one request to use a specific allocator instance', are you talking about providing such an allocator for _users_ of the library, or are you talking just about handling memory allocation internally?
The user of the library would provide the allocator, and the library would "call back" into the user for memory allocation and deallocation.
The allocator would be per-request ideally, so that when we are using an extension that allows handling of multiple simultaneous requests in the same process (or fold the gateway code into the HTTPd, as is done on some devices), we can keep the allocations made for each request separate.
I was planning on abstracting memory allocations to an allocator for the FastCGI/SCGI parameters, as an internal template argument. I'm not sure if what I have in mind would be flexible enough though... Perhaps when I've started properly coding the current ideas I could drop you an email and see how far off I am? In the meantime, I'll try to keep it in mind. Thanks, Darren
Darren Garvey wrote:
Hello all,
In preparation for working on a cgi library for the Summer of Code (proposal: cgi.sf.net/proposal.html), I'd like to collect a list of use-cases for such a library.
The purpose of this discussion isn't to decide what goes into the library (the scope will be limited to CGI, FastCGI and possibly SCGI backends) - although please don't let that censor your thoughts - but to ensure the library is structured in such a way to allow the widest potential for expansion.
Of particular interest are thoughts about: - CGI vs. HTTP: if the library worked with (for example) mod_proxy_http, would the 'limitation' of only providing CGI variables be an acceptable compromise for the sake of portability across protocols?
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.
- 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.
- low-level design decisions
It would be great if multiprocess and multithreading designs would be supported, respectively. 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. Support for streaming could be interesting (not sure if that can actually be done in the CGI world, though). HTH, m
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
Darren Garvey wrote:
On 22/04/07, Martin Wille wrote: [...]
Noted. Incidentally, I figured WSGI wasn't a protocol per-se, but a framework for handling multiple protocols?
Hmm, you seem to be right. The text at http://www.wsgi.org/wsgi/What_is_WSGI mislead me, as it somehow seems to imply a protocol.
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).
Well, then it's better to do what can be done within the timeline well instead of failing the job in the attempt to add a boatload of features.
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.
Which do you expect to be controversial: session management per se or cookie-free session managment?
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.
I was not talking about C++ streams. I was talking about sending a stream over HTTP, see http://en.wikipedia.org/wiki/HTTP_streaming Regards, m
On 23/04/07, Martin Wille <mw8329@yahoo.com.au> wrote:
Darren Garvey wrote:
On 22/04/07, Martin Wille wrote: [...]
Noted. Incidentally, I figured WSGI wasn't a protocol per-se, but a framework for handling multiple protocols?
Hmm, you seem to be right. The text at http://www.wsgi.org/wsgi/What_is_WSGI mislead me, as it somehow seems to imply a protocol.
I really wasn't sure myself; I had to reread that a couple of times to be 'sure'. *sighs* [snip]
Well, then it's better to do what can be done within the timeline well instead of failing the job in the attempt to add a boatload of features.
Yeah, I agree. The library isn't exactly Rome, but I should probably build it using the same rules (ie. in stages).
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.
Which do you expect to be controversial: session management per se or cookie-free session managment?
I expected session management in general to be controversial - mainly because it involves security, which usually seems to fan flames - but the idea seems to have support. Of course adding support isn't vital, but I think this'll be first on the list of things I'll do if all the rest goes to plan. I was not talking about C++ streams. I was talking about sending a
stream over HTTP, see http://en.wikipedia.org/wiki/HTTP_streaming
Oh yeah! :) IIUC, support for HTTP streaming requires only two things: the ability to say the transfer encoding is chunked, and some way to route requests from the same user to the same place. If that's all, then streaming wouldn't actually require any extra library code to use. (please correct me if I'm missing something) If, for example, you had ticker info for a client, you could send out a bit, then notify the program what state the client is in (ie. how far along the ticker they are). When another request comes in you just look up the client state, go to that point in the tracker and continue processing. Alternatively, you could supply your own event handler to the library (this is something that should be possible anyway, IMO) which _does_ route requests; routeing by default would probably incur too much overhead. Thanks, Darren
Hello, I assume this is already known, but just in case it is overlooked, I hope the people working on this Summer of Code project take a look at existing implementations for ideas. One, for example, is Peter Simons' libfastcgi: http://cryp.to/libfastcgi/ - Chris On Sun, Apr 22, 2007 at 06:20:35AM +0100, Darren Garvey wrote:
Hello all,
In preparation for working on a cgi library for the Summer of Code (proposal: cgi.sf.net/proposal.html), I'd like to collect a list of use-cases for such a library.
The purpose of this discussion isn't to decide what goes into the library (the scope will be limited to CGI, FastCGI and possibly SCGI backends) - although please don't let that censor your thoughts - but to ensure the library is structured in such a way to allow the widest potential for expansion.
Of particular interest are thoughts about: - CGI vs. HTTP: if the library worked with (for example) mod_proxy_http, would the 'limitation' of only providing CGI variables be an acceptable compromise for the sake of portability across protocols? - how significant SCGI is (would anyone use it?); - non-CGI/FastCGI/SCGI/HTTP protocols that might be of interest; - low-level design decisions
There's going to be a lot of work put into this library over the Summer, so now is the best time to impress your ideas on us, before they're 'set in stone', so to speak.
Regards, Darren _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Chris, On 25/04/07, Chris Frey <cdfrey@foursquare.net> wrote:
I assume this is already known, but just in case it is overlooked, I hope the people working on this Summer of Code project take a look at existing implementations for ideas.
I 'once' looked at every cgi-ish library on sourceforge. My eyes still occasionally bleed. ;) http://cryp.to/libfastcgi/ This is the first library I found, and was the inspiration for me starting on this library (before SoC came around). It's a pity it isn't complete. I'm very grateful Peter Simons (who pops up on this list now and then) put it out there. Thanks, Darren P.S. This paper by him is a good one: http://cryp.to/publications/fastcgi/
I have looked into a few too. We definately need a boostified one. Cause most of them are either incomplete, unmaintained or broken... Thanks Shams -- "Darren Garvey" <lists.drrngrvy@googlemail.com> wrote in message news:1be3e4b20704251605l1804757cge34c1226168f84b7@mail.gmail.com...
Hi Chris,
On 25/04/07, Chris Frey <cdfrey@foursquare.net> wrote:
I assume this is already known, but just in case it is overlooked, I hope the people working on this Summer of Code project take a look at existing implementations for ideas.
I 'once' looked at every cgi-ish library on sourceforge. My eyes still occasionally bleed. ;)
This is the first library I found, and was the inspiration for me starting on this library (before SoC came around). It's a pity it isn't complete. I'm very grateful Peter Simons (who pops up on this list now and then) put it out there.
Thanks, Darren
P.S. This paper by him is a good one: http://cryp.to/publications/fastcgi/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi guys,
In my humble opinion, the best design decision about libfastcgi was the strict separation of protocol know-how and I/O code. The library interprets memory buffers as input and produces memory buffers as output. Because of this trait, it integrates nicely with all kinds of I/O scheduling mechanisms, whether it is blocking, non-blocking, or asynchronous I/O. I would hope that a new and improved Boost.FastCGI library is implemented the same way. It is tempting to go for tight integration with Boost.Asio, for instance, but my recommendation is to avoid such a dependency. libfastcgi is released under an all-permissive license. If the code can be re-used in one way or another, I'd be all for it. I guess, however, that implementing FastCGI from scratch is ultimately easier than trying to get that rather old code up to speed. Best regards, Peter
participants (9)
-
Chris Frey -
Darren Garvey -
Jeff Garland -
Jose -
Martin Wille -
Peter Simons -
Shams -
Simon Richter -
Steven Siloti