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
