Re: [boost] Fwd: [Boost-users][RFC] Preferred API for a CGI library proposal

From: Darren Garvey (lists.drrngrvy_at_[hidden])
Date: 2007-04-06 15:13:41

On 06/04/07, Cory Nelson <phrosty_at_[hidden]> wrote:
>
> I think GET should be parsed immediately, and POST should be read in
> by the user.  Maybe have an adapter class that can decode POST data if
> the user wants it like that?

Such an adapter class could be very useful. I was thinking that a
boost::iostreams::filtering_streambuf might be ideal for this. That way, it
should be relatively simple for a library user to add in their own filter if
they want to do further decoding.

> I agree that shipping FastCGI support is a must - I'm not sure making it
> > completely transparent is the best option - but I agree in principle.
> This
> > discussion is for a separate thread though, perhaps (I've been thinking
> of
> > this for the summer of code (or just the summer...), so input is more
> than
> > welcome)?
>
> Well, normal CGI is already phased out by scripting langs, I imagine
> FastCGI will be the primary use of this library.  Innards can be kept
> to other threads but I think not taking it into consideration while
> discussing the basics of the library would be a mistake.

I didn't mean to imply it shouldn't be discussed, just that I think this
topic is a complex one and probably best discussed in detail. You're right
though: it would be a mistake to ignore the issue this early on...

I do think it could be mostly transparent: the user should be able to
> setup a request handler and either give it to a FastCGI listener or
> attach it to stdin/stdout without code changes.

This idea is one I've just come around to (but not implemented yet). I think
the best solution might be passing a request handler to the FastCGI
listener's constructor, like you mentioned. If the request handler can be
unaware of the protocol that the request came from, that means the request
handler can be used as-is with any 'protocol listener' (I'm calling them
'services', after asio's io_service, for now...) provided by the library or
users of the library.

> By 'async support' you mean for input/output?
>
> Yes, like an asio socket class, with begin_read/begin_write etc.
>
> This is one thing I always see lacking in current web development
> kits: so many of them spend time accessing databases etc, things that
> block and should be done in an async manner, and I bet suffer
> performance because of it.  It would be nice for a change to have an
> API that allows such scalability when it is wanted and ease of use
> when it doesn't matter.
>
> This is not so important for regular CGI but in FastCGI it could be a
> great boon.

I still not sure I see exactly what you mean. As far as my own prototype
goes, asio is at the core of the FastCGI interpreter. It seemed natural for
input and output to be done asynchronously to the thread(s) servicing each
request. In other words, requests are received and parsed and enqueued when
ready, all in one or more background threads; requests are then handled by
other thread(s): These use a streambuf for output, which is sent to the
server when required. Filling the streambuf should be synchronous (to the
thread handling the request); wrapping it in headers and sending it to the
server should be asynchronous. Is this what you mean, or am I miles off? Do
you think the library should provide more than this?

Regards,
Darren