You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cli-dev@httpd.apache.org by Jeff White <jl...@earthlink.net> on 2004/11/28 22:09:00 UTC
Other ways
I had prepared a review of the
mod_aspdotnet source code,
but was afraid all would call it
negative comments. :)
I was told before this is mod_aspdotnet
not mod_NetUsage but are they really
different?
Should there or could there be:
mod_aspdotnet.so CPP files ways
(requiring Visual Studio .NET CPP
for source code adjustments)
mod_aspdotnet1.so CPP that loads an assembly only
(allowing C# or VB.NET or any of
the 50+ languages for source code
adjustments)
mod_aspdotnet2.so CPP that test
"who knows what later"
There would be three compiled
mod_aspdotnet.so CPP zipped
files available (or two or five?).
Is this doable?
This would allow for those who only
use the free available tools (no Visual
Studio .NET CPP needed with assemblies
but I'm told for the CPP way, Visual Studio .NET
CPP is required due to Apache designs).
Plus using assemblies allows for using
AppDomainSetup for the other AppDomains
and other such .NET extra calls (Yes CPP
can add this too but requires Visual Studio
.NET CPP).
A CPP file is needed to load the CLR,
but after that can it all be done in .NET,
and still keep Apache's pools, and etc.
for the larger sites or maybe a different
mod_aspdotnet version for smaller sites?
Any thoughts?
Jeff
Re: Other ways
Posted by Jeff White <jl...@earthlink.net>.
From: "William A. Rowe, Jr."
>>
>>>If the security was enabled
>>
>>Such as...
>
> The fact that a normal application security model won't let us...
>
Define your normal security model then....
>>>to allow the .NET managed space to instance System.Web.Hosting,
>>
>>You mean calling CreateApplicationHost?
>>In an already running .NET process?
>
> Yes and drive the ApplicationHost from the .NET process...
>
Are you saying you cannot get any .NET
C# process, stand alone or inside Apache
or both, to load and call the member method
ApplicationHost.CreateApplicationHost
and then use the returned object, to provide
ASP.NET functions?
Jeff
Re: Other ways
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:30 AM 11/30/2004, Jeff White wrote:
>From: "William A. Rowe, Jr."
>
>>If the security was enabled
>
>Such as...
The fact that a normal application security model won't let us...
>>to allow the .NET managed space to instance System.Web.Hosting,
>
>You mean calling CreateApplicationHost?
>In an already running .NET process?
Yes and drive the ApplicationHost from the .NET process...
>>then yes, you could implement ASP.NET as a pure .NET solution :)
>
>ASP.NET is in and running in .NET already....
No other way around. mod_dotnet isn't going to be ASP.NET
(thought I covered that before - thought it was part of what
you and others were looking for). It will be a normal CLR
instance.
With full access to all Apache's hooks, it can either run
side-by-side with mod_aspdotnet, or an ASP.NET handler could
easily be coded in Apache.NET (mod_dotnet) as a pure .NET
implementation.
Anyways, that would be a much later game to play. I'm going
to start with the primitives for connection and request rec,
and body read/write before I go much further, as a proof
of concept. Once my holiday break arives, that is.
Bill
Re: Other ways
Posted by Jeff White <jl...@earthlink.net>.
From: "William A. Rowe, Jr."
>
> Let me point out one amusing aspect.
Okay...
Notice: I do not follow the below statements.
> If the security was enabled
Such as...
> to allow the .NET managed space
> to instance System.Web.Hosting,
?
You mean calling HttpWorkerRequest?
You mean calling CreateApplicationHost?
You mean calling HttpContext?
In an already running .NET process?
?
> then yes, you could implement ASP.NET
> as a pure .NET solution :)
ASP.NET is in and running in .NET already....
?
You mean calling HttpWorkerRequest?
You mean calling CreateApplicationHost?
You mean calling HttpContext?
In an already running .NET process?
?
I'm confused...
Please provide a few lines maybe in
outline form or flow chart style that
demos what you are saying....
Or perhaps, a short none Apache based
demo...
Jeff
Re: Other ways
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:10 AM 11/29/2004, William A. Rowe, Jr. wrote:
>At 03:09 PM 11/28/2004, Jeff White wrote:
>
>mod_aspdotnet serves one very specific purpose, to serve ASP.NET
>content from httpd on Win32. Nothing more nothing less.
>
>>Should there or could there be:
>>
>>mod_aspdotnet1.so CPP that loads an assembly only
>>(allowing C# or VB.NET or any of the 50+ languages for source code adjustments)
>
>Please - not mod_aspdotnet1 - why not simply mod_dotnet.so?
>
>That is a direction we are all thinking of moving in.
>
>We can keep extending mod_dotnet, if it is sufficiently broad
>in scope. It would -not- serve ASP.NET - it would be for loading
>.NET code into Apache-space. (And yes - no issue with running
>both modules.)
Let me point out one amusing aspect. If the security was enabled
to allow the .NET managed space to instance System.Web.Hosting,
then yes, you could implement ASP.NET as a pure .NET solution :)
Bill
Re: Other ways
Posted by Yussef Alkhamrichi <ya...@hotmail.com>.
>I envision two namespaces, Apache::native and Apache::Server, which
>would extend Apache 2.x to dotnet.
>This isn't trivial code, we probably need to start from the bottom
>(say, the APR library), but I have quite a few cycles during the
>holidays to spend on this. Any other volunteers to get hacking?
I've my hands free during the last two weeks of this year, I could join some
nasty hacking :)
Wouldn't it be an idea to have a look at AnkhSvn (svn pluging for VS.NET)? I
think they also will have wrapped a part of the APR to be able to use it in
.NET (maybe I'm mistaking in the sense that they are only using client
portion stuff of the APR and for the mod_aspdotnet we are interested in de
server side of the APR).
Yussef
_________________________________________________________________
Talk with your online friends with MSN Messenger http://messenger.msn.nl/
Re: Other ways
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:09 PM 11/28/2004, Jeff White wrote:
>I had prepared a review of the
>mod_aspdotnet source code,
>but was afraid all would call it
>negative comments. :)
All code review is a positive thing, even if the committers
can't agree on the 'one true way'.
>I was told before this is mod_aspdotnet
>not mod_NetUsage but are they really different?
Yes. They are.
mod_aspdotnet serves one very specific purpose, to serve ASP.NET
content from httpd on Win32. Nothing more nothing less.
>Should there or could there be:
>
>mod_aspdotnet1.so CPP that loads an assembly only
>(allowing C# or VB.NET or any of the 50+ languages for source code adjustments)
Please - not mod_aspdotnet1 - why not simply mod_dotnet.so?
That is a direction we are all thinking of moving in.
>mod_aspdotnet2.so CPP that test "who knows what later"
We can keep extending mod_dotnet, if it is sufficiently broad
in scope. It would -not- serve ASP.NET - it would be for loading
.NET code into Apache-space. (And yes - no issue with running
both modules.)
>Is this doable?
Certainly hope so.
>This would allow for those who only
>use the free available tools (no Visual
>Studio .NET CPP needed with assemblies but I'm told for the CPP way, Visual Studio .NET
>CPP is required due to Apache designs).
And it will remain a requirement for the short term. Perhaps
in the long term, we will be able to cleanly separate out the
PInvoke stubs, and avoid having a mixed native/managed assembly.
But I do wonder what the other half will look like, and suspect
we will continue to have a .c or .cpp thunk within Apache.exe's
module.
>Plus using assemblies allows for using AppDomainSetup for the other AppDomains and other such .NET extra calls (Yes CPP can add this too but requires Visual Studio .NET CPP).
>A CPP file is needed to load the CLR,
>but after that can it all be done in .NET,
>and still keep Apache's pools, and etc. for the larger sites or maybe a different mod_aspdotnet version for smaller sites?
Actually, it can't all be done in managed .net - we need some
IJW accessors or PInvoke thunks to dive back into unmanaged space.
I envision two namespaces, Apache::native and Apache::Server, which
would extend Apache 2.x to dotnet. The ::native would be direct
access to the PInvoke stubs. The ::Server would be .NET abstraction
which could handle all the ugliness (e.g. RequestRecord would be
a .NET class, not a thunked c object.) Using methods of the ::Server
classes it would adjust the in-.NET flavor and update the native
structures as needed.
Apache::Pool would wrap the pool api, Apache::Server::Connection
would wrap the conn_rec. One of the tricky bits, Apache::Hook
would provide some generic accessors for the hook registration
API, and Apache::Server::PreConfig would be the template for
coding a PreConfig event handler, with the appropriate delegates
then extended from the unmanaged (native Apache) side.
This isn't trivial code, we probably need to start from the bottom
(say, the APR library), but I have quite a few cycles during the
holidays to spend on this. Any other volunteers to get hacking?
Bill