[Mono-list] Mono vs. ASP.NET Design

[Patrik Torstensson]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C19B87.234D57CC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

I have been looking into how to fix the ASP.NET support in Mono, my
focus has been on getting the runtime to work and I haven't look at the
parsing and everything that gets executed during a request. My first
goal is to get the runtime to work and make a good abstraction model
that also will make it possible to implement the Mono.WEB runtime on any
web server and still be compatible with existing ASP.Net applications
(without doing a complete reverse enginering of MS platform and the
current ASP.Net implementation). My suggestion is that we remove a
number of existing MS classes (both public and internal) that we have
done up to this point, the only classes we need to support are the one's
used by developers outside (and maybee inside) MS and not the ISAPI
implementation classes. There is a number of reasons for this but the
main one is of course that MS has not developed the framework to support
any other Web server.=20

This is my notes about Mono vs ASP.NET implementation (to become Mono
implementation I would say). I'm currently have developed the
HttpResponse, HttpRequest classes and also a number of the support
classes but they are not yet commited to Mono due to that need to fix
the startup and request flow first.

ASP.NET Startup flow
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Interfaces:
 IAppDomainFactory is exposed via COM interopt
 IISAPIRuntime interface is exposed via COM interopt (may be used to
ProccessRequest)

ASP.Net (Unmanaged code) uses the AppDomainFactory that it uses to
create the ISAPIRuntime class and from there aspnet_isapi.dll can then
use the IISAPIRuntime::ProcessRequest to execute a request, from that
point everything is in managed code (I think).

All the HTTP classes then uses a special unsafe managed class to talk to
the aspnet_isapi.dll, there also exists a safe managed class that uses
interopt for functions that don't need to be unsafe.

Mono Impl Aspects
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I think all of the above interfaces and functions (all interfaces and
classes under Hosting) are not needed in the Mono implementation and I
think Microsoft should have made them Internal but probably other MS
projects are using the Worker implementations and therefore they are
public. They are not used by any developer right now and no developer
(outside MS) can really use them).

I think the Mono project should almost make the same implementation
except a few classes that we need to make more abstract to make it
possible to easy change web server implementation. I'm can implement
this if everyone agree's that we don't need to reverse engineer (or
should I say Copy) the undocumented MS way. This also includes the
internal of HttpRuntime (we only need to keep the public methods).

I would like to have a TCP/IP unmanged C code to kick of Mono runtime
and use a class (AppFactory) to get the IHttpRuntime interface that then
the unmanaged code can use to post requests. The AppFactory can then
provide different implementations depending on parameters (web server
type etc) and this is like the MS implementation but they have named the
interfaces like IISAPIRuntime with is not a good name.


ASP.NET Execution vs Mono impl
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
This is not that complex, it executes a request via the
HttpRuntime::ProcessRequest(HttpWorkerRequest) and we should use the
same public methods here, we need to look at the security implementation
and the unmanaged callbacks (like mappath etc) but in the begining they
could be a managed class created via the same AppFactory as the
unmanaged code uses (and then different web servers can register
different unmanaged callback classes).

From there we need to implement the support for the IHttpHandler and
IHttpModule interfaces and all of the context classes (I have almost
implemented all of them except the App class).

Comments? I would like to kick this of, we need to have a number of
people also working on the System.Web.UI parser and executor that is the
next step. I'm planning of using a own web server (in C#) as test bed
for the classes. If I draw up the architecture and implement the basics
then the rest of the System.Web contributors can start doing the extra
functions ( a lot is still to be implemented) like the session handling,
caching, tracing and of course the the .ASPX execution (Page object in
System.Web.UI)

Best Regards
 Patrik Torstensson


------_=_NextPart_001_01C19B87.234D57CC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.5762.3">
<TITLE>Mono vs. ASP.NET Design</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Verdana">Hi All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">I have been looking into how to fix =
the ASP.NET support in Mono, my focus has been on getting the runtime to =
work and I haven't look at the parsing and everything that gets executed =
during a request. My first goal is to get the runtime to work and make a =
good abstraction model that also will make it possible to implement the =
Mono.WEB runtime on any web server and still be compatible with existing =
ASP.Net applications (without doing a complete reverse enginering of MS =
platform and the current ASP.Net implementation). My suggestion is that =
we remove a number of existing MS classes (both public and internal) =
that we have done up to this point, the only classes we need to support =
are the one's used by developers outside (and maybee inside) MS and not =
the ISAPI implementation classes. There is a number of reasons for this =
but the main one is of course that MS has not developed the framework to =
support any other Web server. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">This is my notes about Mono vs =
ASP.NET implementation (to become Mono implementation I would say). I'm =
currently have developed the HttpResponse, HttpRequest classes and also =
a number of the support classes but they are not yet commited to Mono =
due to that need to fix the startup and request flow first.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">ASP.NET Startup flow</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Verdana">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">Interfaces:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Verdana">&nbsp;IAppDomainFactory is exposed =
via COM interopt</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Verdana">&nbsp;IISAPIRuntime interface is =
exposed via COM interopt (may be used to ProccessRequest)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">ASP.Net (Unmanaged code) uses the =
AppDomainFactory that it uses to create the ISAPIRuntime class and from =
there aspnet_isapi.dll can then use the IISAPIRuntime::ProcessRequest to =
execute a request, from that point everything is in managed code (I =
think).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">All the HTTP classes then uses a =
special unsafe managed class to talk to the aspnet_isapi.dll, there also =
exists a safe managed class that uses interopt for functions that don't =
need to be unsafe.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">Mono Impl Aspects</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Verdana">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Verdana">I think all of the above interfaces =
and functions (all interfaces and classes under Hosting) are not needed =
in the Mono implementation and I think Microsoft should have made them =
Internal but probably other MS projects are using the Worker =
implementations and therefore they are public. They are not used by any =
developer right now and no developer (outside MS) can really use =
them).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">I think the Mono project should =
almost make the same implementation except a few classes that we need to =
make more abstract to make it possible to easy change web server =
implementation. I'm can implement this if everyone agree's that we don't =
need to reverse engineer (or should I say Copy) the undocumented MS way. =
This also includes the internal of HttpRuntime (we only need to keep the =
public methods).</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Verdana">I would like to have a TCP/IP =
unmanged C code to kick of Mono runtime and use a class (AppFactory) to =
get the IHttpRuntime interface that then the unmanaged code can use to =
post requests. The AppFactory can then provide different implementations =
depending on parameters (web server type etc) and this is like the MS =
implementation but they have named the interfaces like IISAPIRuntime =
with is not a good name.</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Verdana">ASP.NET Execution vs Mono impl</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Verdana">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Verdana">This is not that complex, it =
executes a request via the =
HttpRuntime::ProcessRequest(HttpWorkerRequest) and we should use the =
same public methods here, we need to look at the security implementation =
and the unmanaged callbacks (like mappath etc) but in the begining they =
could be a managed class created via the same AppFactory as the =
unmanaged code uses (and then different web servers can register =
different unmanaged callback classes).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">From there we need to implement the =
support for the IHttpHandler and IHttpModule interfaces and all of the =
context classes (I have almost implemented all of them except the App =
class).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">Comments? I would like to kick this =
of, we need to have a number of people also working on the System.Web.UI =
parser and executor that is the next step. I'm planning of using a own =
web server (in C#) as test bed for the classes. If I draw up the =
architecture and implement the basics then the rest of the System.Web =
contributors can start doing the extra functions ( a lot is still to be =
implemented) like the session handling, caching, tracing and of course =
the the .ASPX execution (Page object in System.Web.UI)</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Verdana">Best Regards</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Verdana">&nbsp;Patrik Torstensson</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19B87.234D57CC--