[Mono-list] mod_mono

[Darren Martz]

Gonzalo,
 
I have been looking over the mod_mono source and have a few thoughts. Before
you read on, please don't take offence to anything I write that may
accidentally offend... I am just trying to help.

It seems the way to create a separate mod-mono-server process per
"MonoApplication" is to change the MonoUnixSocket value to a unique address,
or use unique MonoListenAddress/MonoListenPort values. On Linux a unique
.wapi directory is also necessary using the MonoWapiDir statement.

Pooling MonoApplications into one or more mod-mono-server processes is not
an obvious outcome of MonoUnixSocket and MonoWapiDir. The MonoWapiDir only
makes sense to people working on XSP and mono, and the MonoUnixSocket is not
likely to be relevant in a Windows environment - assuming a port to Windows.

What if we combined all of that into something a bit more direct, something
like the following entries:

	MonoGroup $GroupName
	MonoTemp /tmp/mod_mono/

[the notation of $GroupName indicates to replace with your own groupname
such as "nGallery"]

The MonoTemp sets a generic temp directory where both the .wapi directory
and the mod-mono-server socket exist. That is the equivalent of writing the
following with today's syntax:

	MonoUnixSocket /tmp/$GroupName/mod-mono-server
	MonoWapiDir /tmp/$GroupName/.wapi

So why consider changing the syntax? The entries are completely unique to
Linux requiring a new set of commands for a Win32 port. The outcome of using
these commands is to control unique processes of mod-mono-server regardless
of the host platform. This is our way of controlling groups of
MonoApplications/mod-mono-server processes, what I'll refer to as
"application pools". A common syntax that supports application pools across
multiple platforms seems logical/ideal.

Due to bug #50049 we apparently need to create a unique mod-mono-server
process per MonoApplication.

On Linux this means the mod-mono-server file and the .wapi directory always
reside in the same [sub]directory. Maybe that is a problem for a few, but I
understand others are already doing it manually. Others have created scripts
to cleanup the .wapi and mod-mono-server reminisce when apache is
reloaded/stopped - something mod_mono could do in the terminate_xsp
function.

Porting mod_mono to Windows *could* mean that MonoTemp is ignored (or used
for something else) and MonoGroup translates into a named pipe called
"//./pipe/mod-mono/$GroupName", or shared-memory name, or something like
that. That means the syntax/documentation could remain constant between
Unix/Linux/Mac/Windows but allow for an OS optimized implementation.

My interest in this? Coming from the windows C/C++ world I'd like to see an
alternative on Windows for asp.net and am considering writing the port
myself if nobody else is up to the challenge. That would help many
businesses wanting to move away from IIS but towards Asp.Net that are not
ready to commit to a Linux platform.

Cheers, 
Darren