At 01:51 PM 8/10/2004, Jeff White wrote: >By the way, does the CLI include: > >System.Web
For mod_aspdotnet? Yes. For a future Apache.Web interface? No, because that would preclude every CLR implementation which implements the ECMA spec, and avoids potential IP claims by Microsoft over non-ECMA implemenations. >System.Data >System.WinForms >(and any (?) .NET 2.0 goodies) No - in so far as they don't apply to this container. If you use them, wonderful, if you don't (e.g. if they are not implemented in your CLR implementation) then that's fine too. >> subproject, yup :) > >Subproject? Yes - subproject of httpd server. >Why not first with a simple "hello world" >Apache2 .NET module by using (MC++) >Managed Extensions? Why/Why not? Feel free to offer one. >More on this latter... > >> Subgoal one, behind releasing the >> first mod_aspdotnet module, > >So nothing will (can) be done until >"mod_aspdotnet" is first released? First off; project details can be found here; http://incubator.apache.org/projects/httpd-cli.html ... however it's out of date - seems to need a regeneration. (the .cwiki file has been updated - Ian? could you help here?) Answer to your Q ... No. Although mod_aspdotnet should be ready for release. The source can be downloaded here; http://svn.apache.org/repos/asf/incubator/httpd/cli/trunk/ >Which is when? > >And the reasons why mod_aspdotnet >must be first? No... no reason. It's simply glue that allows users to run MS's ASP.NET implementation today, just as the mono's mod_mono connector allows the mono user to do the same. >> Subgoal one, behind releasing the first >> mod_aspdotnet module, is to separate >> the COM instantiation from the rest of the >> System.Web support. > >I do not follow, please explain..... If you review the code, you will find the COM thunks to the ASP.NET engine (native -> CLR) and managed/native thunks (.NET -> httpd) are littered throughout the code. This has to become more granular so that a non-com implementation like mono can be plugged in. Note, too, that mod_aspdotnet creates ASP.NET managed instances. It does not create arbitrary CLR assembly instances. Once it is abstract enough - one side which loads a .NET managed runtime (arbitrary, such as MS's or mono's)... and one side which thunks back to httpd native code (again, based on a specific CLR), then the Apache.Web namespace can be constructed. >> This will allow folk to plug other CLR >> environments into our framework. > >I am lost again, > >"other CLR environments"? Uhm, it's not only about MS. They (MS & partners) defined an ECMA CLR specification. The actual implementation details, e.g. using COM for native -> managed transitions, aren't part of that spec. >"into our framework"? > >Please provide a simple worded >example of these.... Microsoft .NET Microsoft Rotor mono ... others as they come to exist. >> Then, begin declaring Apache.Web >> classes that get right to the heart of >> the httpd server to write Apache modules >> in any preferred language. > >Please provide a simple worded >example of these "right to the heart".... See httpd-2.0/include/*.h >Also will there not be Apache.Admin >"type" classes or even Apache.Dev >"type" classes or Apache.Basic.Mod >"type" classes? ??? Why? Again, see httpd-2.0/include/*.h The goal is to allow .NET development of an httpd module. This means that the implementation allows a module written in .NET to access any httpd native structures and entry points. More complex entities, say for example, a .NET GC'ed bucket, could be designed specifically for the .NET style of development. >Allowing "any type" of assemblies to be >loaded will increase the above classes >chances of development.... >(free SDK compilers) > >By releasing a simple .NET assembly >loader, this would allow the learning of the >.NET classes, as well as learning "hosting".... There is an ASP.NET host assembly loader in mod_aspdotnet. This has to become (more broadly) a .NET assembly loader. >No need to have all, get out a .NET C++ that >does full COM first, but perhaps that and MC++..... > >Try a simple MC++ "Hello World" module. > >For example: > >Try adjusting the Ryan Bloom's "Example >Module", a text Hello World module, on pages >169-174 in his book, Apache Server 2.0. > >But adjust the text output for "Hello World" >into a complete HTML file by using .NET's >StringBuilder (to write the html code). Then >compile the module as a MC++ file.... You can do this today. We hope that users won't require the MC++ to write .NET Apache modules. C# is the 'natural' way to write to the CLR, once an author can write in that language, I believe they will be able to write from any ECMA .NET language. Bill
