It looks like it's just about time for another major release of NWSGI - the last two Decembers have had major releases, and I see no need to break the trend this year. There are going to be a few major changes this time around, so if anyone has any objections, let me know as soon as possible.
Most importantly, it will only support IronPython 2.7 and thus will require .NET 4.0. Like the IronPython team, I'm not going out of my way to break compatibility with .NET 2.0 (or IronPython 2.6, for that matter), but I won't be distributing anything but IronPython 2.7/.NET 4.0 binaries.
Similarly, I will not be supporting IIS 6 (Windows Server 2003) anymore. Again, I won't go out of my way to break it, but I won't be testing against it either. This means I can get rid of the wildcard handling for good, since IIS 7 has a good URL rewriter available.
The biggest change is that I am decoupling the WSGI processing from the ASP.NET pipeline. All of the functionality is currently part of an IHttpHandler implementation, which restricts it to be used with IIS (and Cassini) only. NWSGI 3.0, on the other hand, will allow NWSGI to be used with HttpListener or other servers such as Kayak by moving all WSGI processing into a separate class with no ASP.NET dependencies. The redesign will also allow me to improve the test coverage from zero to, well, something.
Finally, the licence will change to the Apache Licence 2.0 to match IronPython. The basic terms are identical to the Ms-PL licence that was used previously; the Apache licence is just more explicit and also more widely used.
As with the previous versions, I expect to release the final version shortly after IronPython 2.7 is released.
Hi.
ReplyDeleteAs part of my "bring Smart HTTP GIT server to all WSGI-enabled servers" project (git_http_backend.py on GitHub) I needed a subprocess.py module for IronPython (http://github.com/dvdotsenko/IronPythonParts/)
My primary target deployment is NWSGI on IIS (v6 at this time, as our conservative shop has no plans to migrate from Win2003 any time soon).
Have a question regarding NWSGI handling security level settings and of .Net threads as called by IronPython process.
Do you anticipate any issues with MWSGI IronPython processes spawning (and waiting on) 2-3 threads?
I am clueless about the "Full" etc security setting implications and was hoping to hear from you on the subject. What's the minimum security level preset NWSGI is capable of running at?
Hi Daniel,
ReplyDeleteAnd here I thought my company would be the last off of IIS 6 :). I don't plan on doing extensive testing with IIS 6, but I certainly don't want to intentionally break it. NWSGI 2.0 should continue work just fine on IIS 6, though.
As for security, Full trust is what it says - you can do anything; in particular, you can execute arbitrary native code. Medium trust removes a bunch of permissions, but it mostly just prevents writing to arbitrary filesystem locations and running untrusted native code (I can't actually find a decent reference of what it restricts).
IronPython by itself should be fully supported in medium trust, but libraries may require extra permissions. NWSGI should also work just fine in Medium (and it's a bug if it doesn't!), but an application may not, because most Python web apps don't expect Medium trust.
Medium trust is an area I don't test as well as I should, so there may be some lingering bugs; let me know if you find any.
You should be fine for threading; lots of waiting threads is fine - lots of busy threads is another issue :). I assume you plan on using the Python threading (or thread) module. This *should* work just fine in medium trust, but you'd have to check to be sure.
I look forward to seeing your project; for various reasons, I have only run simple apps on NWSGI, so it will be good to get a more demanding application to really test it out.
- Jeff