[Mono-dev] FastCGI, was: Silverlight early implementation thoughts.
robertj at gmx.net
Mon May 7 15:29:49 EDT 2007
Marek Habersack wrote:
> On Mon, 07 May 2007 11:27:15 -0400, Miguel de Icaza <miguel at novell.com>
>>> It's basically a "persistent CGI" application which communicates with the
>>> server over a unix|tcp socket using a well-defined protocol. Basically, what
>>> mod_mono does but not mono-specific and not tied to apache. It's what
>>> mod_mono should've been from the start. We're going to keep maintaining
>>> mod_mono, but I expect most development effort in this area will go into
>>> the FastCGI server (no matter what is the outcome of the SoC project)
>> One requirement that I have is that the FastCGI bridge supports
>> auto-configuration, or some other easy form of configuration.
> Yep, that will be part of the implementation, although I believe it is more a
> feature of xsp itself than a bridge.
I doubt FastCGI would be easier to configure.
Let's have a look at a typical FastCGI configuration:
Alias /aspnet-app-name /usr/lib/mono/www/mono-fastcgi-server
If the whole URL namespace should be consumed by mono
(e.g. to enable ASP.NET application auto-confguration),
the apache config gets even worse:
Alias /mono-global-handler /usr/lib/mono/www/mono-fastcgi-server
Action mono-handler /mono-global-handler
Configuring an application-to-mono-process mapping, easily
to achieve with mod_mono, will become a nightmare with FastCGI.
Moreover, the config snippets above must be inserted in
every vhost, otherwise the vhosts will share the same
And since HttpResponse.TransmitFile won't be as efficient as it
used to be under mod_mono (which simply passes the file name
to apache), even more apache config voodoo is required (and that's
the best case).
More information about the Mono-devel-list