A slightly different take on “Qt Everywhere” :: Blog

A slightly different take on “Qt Everywhere”

(posted at 2009-02-01 15:00:54 UTC)

Skip to comments

Firstly, as a bit of context, I think that in large applications, having a more detailed type system than just "scalar", "array", and possibly objects really helps, and speeds up debugging, and helps bring up errors at compile time instead of runtime, which is always a good thing. I don't see how this doesn't apply to large web applications equally as desktop applications; to an extent, Java servlets seem to be almost what I want; unfortunately, I don't like Java (I won't go into that here) - and I like Qt :)

Because of this, I've started writing FastCGI-Qt, a library to make writing FastCGI applications using C++/Qt as simple as possible - as demonstrated by the example on the first page of the documentation (more are linked at the bottom of that page).

It is currently only tested under Apache HTTPD 2.2 with mod_fastcgi-2.4.6, but supporting other servers is on my to-do list.

The current feature set is:

• Handle communication with the mod_fastcgi, and create instances of your class as necessary to respond to each request.
• Makes HTTP headers and POST data available.
• Parses any form-encoded variables on the query string.
• Provides a stream interface for reading POST data (responders will be created before POST data has been received).
• Parse variables defined in form-encoded POST data (this blocks if the POST data is form data and there is still un-received POST data.
• Defaults to a content-type of text/html and 200 OK status, but this can be overridden if nothing's been sent to the client yet.
• Each application executes requests in parallel, in a thread pool of QThread::idealThreadCount() (typically the number of cores in the system) threads.
• It should handle multiple requests multiplexed over one socket, but mod_fastcgi doesn't do this, so it's untested.

My short-term plans for it include:

• Adding output buffering support.
• Adding support for FastCGI authorizers, not just responders.
• Providing a Responder subclass that you can inherit from and maps request URLs to public slots.
• Writing something non-trivial using it.

It's under the ISC license (with the exception of an internal header file from the fastcgi dev kit, which is under the fastcgi license); there's also QxtWeb which is somewhat similar, but uses SCGI instead of FastCGI, has a different end-user API from what I'm aiming for, and (currently) is only under a GPL-incompatible license.

Comments

New Comment

Drink made from wheat

Your name

Summary

Message

Enter your message here.