= !MapGuide RFC 22 - Replace FastCGI =

This page contains an change request (RFC) for the !MapGuide Open Source project.  
More !MapGuide RFCs can be found on the [wiki:MapGuideRfcs RFCs] page.


== Status == 
 
||RFC Template Version||(1.0)|| 
||Submission Date||(Date/Time submitted)||
||Last Modified||(your name here) [[Timestamp]]||
||Author||(your name here)||
||RFC Status||(draft, proposed, frozen for vote, adopted, retracted, or rejected)||
||Implementation Status||(pending, under development, completed)||
||Proposed Milestone||(e.g. 1.1, 1.3)||
||Assigned PSC guide(s)||(when determined)||
||'''Voting History'''||(vote date)||
||+1||||
||+0||||
||-0||||
||-1||||
 
== Overview ==

This RFC proposes to replace the FastCGI agent on the web-tier with an ISAPI extension and Apache module for IIS and Apache webservers respectively.

== Motivation ==

FastCGI is a protocol for a high performance alternative to CGI for interfacing internet applications with a web server.  Current use of FastCGI has revealed some stability and performance issues relating to this technology (http://trac.osgeo.org/mapguide/ticket/129).  

The current FastCGI implementation for Microsoft Internet Information Server (IIS) was released in 2002 and has not been maintained.  IIS 7 is supposed to feature built-in FastCGI support, however it currently is in beta and should not be considered for use in a production environment.

The Apache module for FastCGI also has not been maintained as the current implementation was released in 2003.  More recently, a binary compatible alternative FastCGI module has been developed by another third party developer to address process management issues, but it's stability and performance is rather unknown.

By replacing the FastCGI agent with an ISAPI extension or an Apache module, the web-tier will be using more proven and stable technologies, as well as reducing the dependency on third party development to address stability and performance issues.

== Proposed Solution ==

This is a more detailed description of the actual changes desired.  The contents of this section will vary based on the target of the RFC, be it a technical change, website change, or process change.  For example, for a technical change, items such as files, XML schema changes, and API chances would be identified.  For a process change, the new process would be laid out in detail.  For a website change, the files affected would be listed.

== Implications ==

This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc.

== Test Plan ==

How the proposed change will be tested, if applicable.  New unit tests should be detailed here???

== Funding/Resources ==

This section will confirm that the proposed feature has enough support to proceed.  This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could act as an RFC author if they are sure they have the funding to cover the change.