Re: [boost] CGI / FastCGI library update

Subject: Re: [boost] CGI / FastCGI library update
From: Darren Garvey (darren.garvey_at_[hidden])
Date: 2010-05-25 16:49:19

Hi Scott,

On 20 May 2010 18:56, Scott McMurray <me22.ca+boost_at_[hidden]> wrote:

> On 20 May 2010 10:58, Artyom <artyomtnk_at_[hidden]> wrote:
> >
> > If so give me one reason why should my application be compiled
> > for each type of these?
> >
> > Good luck :-)
> >
>
> Give me one reason why I should have to link all of those into my
> binary when I only deploy using one of them.
>
> And Thorsten's request is just to make the virtual optional, not to
> remove it altogether.  You can still make it runtime-configurable if
> you insist.
>

I've been tinkering with a dynamic layer above the low-level templated code
that would be runtime-configurable when finished. This has been the first
suggestion I've had from a few people and not an unreasonable request by any
means.

Two things that have come up so far are:

1. The dynamic interface unsuprisingly lends itself to having a compiled
library for the library functions. At this early stage I'm tempted to make
"compiled" the default choice - ie. using the dynamic portion of the library
would simply mean including some declaration-only headers and having
everything else hidden in a single library. This would mean very fast
compiles and small application binaries.

I don't see at the moment why the .cpp files couldn't actually be .ipp files
that could optionally be included in the headers to prevent the need to link
against a CGI library.

2. The dynamic interface seems to lend itself to a really simple Python
binding. I'm not convinced there is any point in going very far down this
route as Python is awash with CGI libraries and WSGI seems to be the
de-facto standard anyway. Still, Python's FastCGI support is based on the
standard FastCGI library so there might be some room for gains.

Thoughts?

Cheers,
Darren