Re: [Cgi-devel] congratulations - couple of general questions

[<jc...@ol...>]

Darren,

Thanks for all the answers.

>> My boost installation is at /usr/local/include/ and I downloaded cgi C++
>> at /websites/libraries. Is there a difference between:
>> #include <boost/cgi/fcgi.hpp>
>> #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp"

> you should prefer the first option. Configure your PATH or
> compiler to search for the correct version of the CGI library and use
> <boost/cgi/fcgi.hpp>

(1) What do I risk if I go with the first second option?

(2) The "installation" section of the doc would benefit from adding a few
lines at the beginning explaining that once the standard boost is compiled
and installed (by default in /usr/local for many linux distro I guess),
then it is only a question of dropping off cgi into
/usr/local/include/boost. As it is now it is unnecessary daunting.

(3) Does the library require the fastcgi toolkit available at fastcgi.com.
Does it contain its own implementation of the FastCGI protocol?

JCR




> Hi,
>
> On 16 June 2010 17:42, <jc...@ol...> wrote:
>
>> Hello Darren,
>>
>> I really like your library and it has improved significantly from a year
>> ago. Congratulations. This is really great to have such a tool. Even for
>> simple apps, using C++ makes sense as you never know how the app will
>> need
>> to scale and it is always good to practice a skill for the day it will
>> be
>> really required. C++ web development involves a more sophisticated setup
>> than let's say php but once it is done it is not really more difficult
>> and
>> it is so much more comfortable. In terms of design, I like that
>> extensions
>> like database access are not in the library but are demonstrated with
>> examples.
>>
>
> I agree. Thanks!
>
>
>> A few (dummy) questions:
>>
>> (1)
>> My boost installation is at /usr/local/include/ and I downloaded cgi C++
>> at
>> /websites/libraries. Is there a difference between:
>>
>> #include <boost/cgi/fcgi.hpp>
>> and
>> #"/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp"
>>
>
> Do you mean:
>
> #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp"
>
> ?
>
> If so, then you should prefer the first option. Configure your PATH or
> compiler to search for the correct version of the CGI library and use
> <boost/cgi/fcgi.hpp>
>
> (2)
>> When you write
>> resp<< content_type("text/plain")
>>    << header("X-Protocol", "FastCGI")
>>    << "Hello there, universe.";
>> is it the same as
>> resp <<
>> with a space
>>
>
> No difference. "resp<<" is calling "basic_response<>::operator<<".
> Whitespace is generally not significant in C++.
>
>
>> (3)
>> Example / async_echo
>>
>> I am trying to compile and I am getting the errors:
>> main.cpp: In function ‘int handle_request(boost::cgi::fcgi::acceptor&,
>> boost::cgi::fcgi::request&)’:
>> main.cpp:116: error: ‘struct
>> boost::cgi::common::basic_request<boost::cgi::common::tags::fcgi>’ has
>> no
>> member named ‘hash’
>> main.cpp: In function ‘int main()’:
>> main.cpp:173: error: no matching function for call to
>>
>> ‘boost::cgi::common::basic_request_acceptor<boost::cgi::common::tags::fcgi>::basic_request_acceptor()’
>> /usr/local/include/boost/cgi/basic_request_acceptor.hpp:33: note:
>> candidates are:
>>
>> boost::cgi::common::basic_request_acceptor<boost::cgi::common::tags::fcgi>::basic_request_acceptor(const
>>
>> boost::cgi::common::basic_request_acceptor<boost::cgi::common::tags::fcgi>&)
>>
>
> Thanks for the report. I removed the support for Boost.Hash as it didn't
> seem necessary, so request.hash() is no longer valid. Also, the acceptor
> constructor needs to take an fcgi::service and can be used the same on
> both
> Windows and Linux. Again, I've attached a patch for this example.
>
> Also, I am wondering what the use case of async_load or async_accept,
>>
>
> These functions are to allow for efficient accepting and loading of
> requests. As an example, if someone wanted to write a high-level web
> development framework, then I imagine that this would include a
> "dispatcher"
> or "server" that was responsible for accepting and loading requests before
> handing them off to application code.
>
> The accepting and loading stages involve accepting connections then
> reading
> and parsing data, which are generally blocking operations. Using the
> async_*
> functions would allow for much more scalable code because OS-specific
> non-blocking APIs could be used under the hood.
>
> I'm not happy with the async FastCGI parts at the moment and have been
> rewriting the FastCGI functionality locally to make them work better. I
> hope
> to get this finished soon.
>
> Cheers,
> Darren
>