
I entered a proposal in for the Summer of Code for what is essentially a CGI library. The lack of comments on that have me wondering if Boost actually wants a library like this and I realised I haven't even asked yet. This isn't about my proposal whatsoever (honest); I just couldn't answer a few questions myself so I'm asking here: 1) Boost is essentially about collecting libraries for possible inclusion in a standard. Is CGI seen as too transient? In other words, do boosters feel such a library belongs somewhere, just not in any standard? 2) Given how (controversial, but) 'simple' such a library is to construct, is there a reason I can't find any mention of a CGI library ever being submitted for review? Have people tried and been shot down earlier? 3) Do people feel that C++ 'just isn't any good for CGI'? I'd disagree, but then of course I would. :) If it's simply down to lack of submissions for pre/review, then that's fair enough (and sorry for the noise). I'd just hate to think I'm building a balcony on a sunken ship. Regards, Darren

Darren Garvey wrote:
I entered a proposal in for the Summer of Code for what is essentially a CGI library. The lack of comments on that have me wondering if Boost actually wants a library like this and I realised I haven't even asked yet. This isn't about my proposal whatsoever (honest); I just couldn't answer a few questions myself so I'm asking here: 1) Boost is essentially about collecting libraries for possible inclusion in a standard. Is CGI seen as too transient? In other words, do boosters feel such a library belongs somewhere, just not in any standard?
Not all Boost libraries are appropriate for standardization -- that doesn't mean they wouldn't be useful. A CGI library probably doesn't belong in the standard...
2) Given how (controversial, but) 'simple' such a library is to construct, is there a reason I can't find any mention of a CGI library ever being submitted for review? Have people tried and been shot down earlier?
My take is that people have been busy with other things. We only recently, finally, finally, got asio for networking. So that might be part of it. I have a hacked version of a cgi library, but haven't had time to really finish or submit it. For small apps it's just easier to write a script at the moment.
3) Do people feel that C++ 'just isn't any good for CGI'? I'd disagree, but then of course I would. :)
Everyone that thinks C++ isn't good for CGI or Web programming more generally, needs only to go to google.com to see C++ in action. BTW, they recently open sourced their c++ templating engine (http://code.google.com/p/google-ctemplate/) used to create various sites. Scripting languages have gotten most of the attention in web programming because there easier for small applications and they have a fully complete 'software stack' for development of web-apps in an easy bundle. I believe C++ can and should have the same thing. That's one of the reasons why 'cgi' was one of the libraries on my 'C++ library roadmap' that I put together 3 years ago for a Boost workshop... http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?OOPSLA2004/Li... These are libraries that from my perspective should be in C++.
If it's simply down to lack of submissions for pre/review, then that's fair enough (and sorry for the noise). I'd just hate to think I'm building a balcony on a sunken ship.
Please keep going. Jeff

Jeff Garland wrote:
Everyone that thinks C++ isn't good for CGI or Web programming more generally, needs only to go to google.com to see C++ in action. BTW, they recently open sourced their c++ templating engine (http://code.google.com/p/google-ctemplate/) used to create various sites.
Note, before reading my critics, that I only went to the link you gave and had a quick look. The template language is not especially impressive, it's very basic stuff. I think better languages can be designed. And the API is not only unimpressive, it also seems pretty bad. To begin with, the code isn't even valid C++ as it uses ' for strings instead of ". It also includes a standard C header instead of the C++ compatible one, uses a bad way to distribute randomness, uses different functions instead of overloading, uses pointers and even worse, the address-of operator instead of things that probably should be references or eventually shared_ptr to share the template throughout the program, writes the output to an std::string (which is taken by pointer instead of returned...)
Scripting languages have gotten most of the attention in web programming because there easier for small applications
That's not only "for small applications". I think you can't expect developers working in web programming to simply be as competent as developers working on say, more advanced matters. This is because the web is trendy and easy to access, lots of inexperienced people are working on it, and there are even quick study courses in some universities nowadays specific for web development. As a result, that kind of developers can't design software as well. And for that, automagic management of resources is what helps.
and they have a fully complete 'software stack' for development of web-apps in an easy bundle.
Certainly, what defines those new scripting languages seems to be at least as much their standard library as themselves. But those languages usually have a reference implementation, backed up by an active group or company that invests lots of money/time in its development. That is quite different with C++.

Mathias Gaunard wrote:
Jeff Garland wrote:
Everyone that thinks C++ isn't good for CGI or Web programming more generally, needs only to go to google.com to see C++ in action. BTW, they recently open sourced their c++ templating engine (http://code.google.com/p/google-ctemplate/) used to create various sites.
Note, before reading my critics, that I only went to the link you gave and had a quick look.
The template language is not especially impressive, it's very basic stuff. I think better languages can be designed.
I don't want to make a big defense of their code, but you should probably look at it a little longer. While it is a spare and minimal template language, to be sure, it provides a fair amount of capability (like repetition and optionality) without alot of primitive notations -- like some other more bloated template languages I've seen. Anyway, my main point was that "the perception" that C++ isn't used for web programming is just wrong.
And the API is not only unimpressive, it also seems pretty bad. To begin with, the code isn't even valid C++ as it uses ' for strings instead of ".
I have no idea what you're referring too -- I've compiled and run tests on my machine, so I assure you it's valid c++.
It also includes a standard C header instead of the C++ compatible one, uses a bad way to distribute randomness, uses different functions instead of overloading, uses pointers and even worse, the address-of operator instead of things that probably should be references or eventually shared_ptr to share the template throughout the program, writes the output to an std::string (which is taken by pointer instead of returned...)
Again, I wasn't holding it out as the way I'd design such code, only that one very notable exception has found C++ useful for web development.
Scripting languages have gotten most of the attention in web programming because there easier for small applications
That's not only "for small applications". I think you can't expect developers working in web programming to simply be as competent as developers working on say, more advanced matters.
Well, ahem, I've spent plenty of time working on more 'advanced matters' in C++, but I've written my fair share of scripts too. I don't think your generalizations hold up.
This is because the web is trendy and easy to access, lots of inexperienced people are working on it, and there are even quick study courses in some universities nowadays specific for web development.
As a result, that kind of developers can't design software as well. And for that, automagic management of resources is what helps.
Automagic management of resources helps expert designers and developers as well because it lets them focus on the problem at hand instead of resource management.
and they have a fully complete 'software stack' for development of web-apps in an easy bundle.
Certainly, what defines those new scripting languages seems to be at least as much their standard library as themselves. But those languages usually have a reference implementation, backed up by an active group or company that invests lots of money/time in its development. That is quite different with C++.
Well all your responses to my email, I think, distract from the main point of my email -- which is, that I'd like to see such a library in Boost. Darren, and maybe others, seem to reflect the "known wisdom" that C++ "isn't good" for web programming, so why bother? My point was that the "known wisdom" is wrong -- many c++ projects could benefit from better tools for web development in general. Other than the lack of good libraries, there's no reason I should write 98% of a project in C++ and then have to jump to 'scripting languagues' just because I need to serve a web page. Jeff

Darren Garvey wrote:
I entered a proposal in for the Summer of Code for what is essentially a CGI library. The lack of comments on that have me wondering if Boost actually wants a library like this and I realised I haven't even asked yet.
A "CGI library" doesn't mean much. If it's only providing code to better interface with the CGI protocol, it shouldn't be much really. Just make sure headers are sent and either provide the size of the content if you can and use chunked encoding otherwise. What's more interesting is to speak about a web library, or whatever you want to call it. But for that, you need lots of features in a fully fledged framework. To begin with, Unicode and eventually support for other encodings would be good. XML also, even if its not used to generate the output document. There is a lot of string management going on in web development, so maybe new ways to handle strings more easily could be also interesting. So basically I think work should be done of those building blocks first.
participants (3)
-
Darren Garvey
-
Jeff Garland
-
Mathias Gaunard