FastCGI?

[pragma]

In article <dv7mpm$1a41$2 at digitaldaemon.com>, Dejan Lekic says...
>
>
>I do not know who Eric is, but from my point, every cooperation on this is
>very much apriciated.

That would be me. ;)

(My apologies if any of this is old hat: I have no idea what frame of experience
you're coming from -- total brain dump to follow)

I have DSP (D servlet pages) on the back-burner right now as I concentrate on
DDL - DSP requires it to make dynamic servlets work in D.  The objective of the
project is to have Java Servlet like capabilities, so you can code in D directly
on a page embedded (or not) within markup.  The major drawback here is that it
requires specalized server support, as a stand-alone server.

As for a fast-CGI module, that would be a nice testbed for a common framework
that I'd be more than happy to throw behind DSP; so provided you open your
development, some of your code might find a home there too!  

For dishing up pages, D now has much more of what's needed than it did two years
ago when I started with all this.  All the XML, logging, parsing, localization,
conversion and unicode handling stuff is now available under Mango and ICU.
Database access is (almost) completely unified under DDBI.  The DDL project
(thanks Lars!) has even contributed a nifty ArgParser under DDL that is
currently making the rounds - feel free to use it for FastCGI.

So what's missing from web-enabled D?  Take a look at the sweeping (overkill?)
runtime support that PHP provides.  If you need something more than just "meat
and potatoes" runtime support, you could probably use some of the very same C
libs that PHP is utilizing to cover all the gaps.  The only problem with this
model, is it requires some kind of conversion/thunk to avoid GC issues when
interfacing with legacy libraries.  Also, as PHP has demonstrated, it'll trend
toward a non-uniform (read: expert system) function reference unless it's kept
in check from the start.

- EricAnderon at yahoo