Hi, Max. Max Ischenko wrote:

I have a really big ASP/IIS-based system which I'm trying to (partially) rewrite and evolve with python.

Congratulations :).

As my python code depends on WebKit very little and Cheetah is a standalone processor that could probably be plugged into Twisted easily I'm evaluating the possibility to switch to Twisted.

There are lots of good reasons to do this, but it doesn't seem like Twisted would do very much for you. The main feature which is the make-or-break point for Twisted is usually multiple protocol support.

There is nothing wrong with Webware/WebKit -- it is a great platform, but I'd like to make use of some Twisted components, like twisted.enterprise.row or twisted.cred.

Personally, I've only used t.e.row once - the Twisted team tends to avoid databases, in general, and while the support for them is there, you'll find it will be more idiomatic in frameworks without Twisted's concern for an asynchronous event loop. Twisted.cred is a very useful framework, but it doesn't really *do* anything, per se; it's a set of interfaces to specify the interactions between a set of the same domain objects and a potentially large number of client protocols. Its HTTP component is currently twisted.web.woven.guard (which is likely to be refactored in the near future because it is too complex for the task it performs...). The real meat of the work going into cred at the moment is for protocols like PB and SIP. Integrating it with Cheetah is likely to be more trouble than it's worth at the moment considering the fairly small number of available credential checker back-ends right now.

If I'm to switch to Twisted what could you suggest for IIS-Twisted integration?

Reverse-proxying is probably best, unless you need some kind of tighter coupling between the servers.

I'm currently thinking about simple Response.Redirect('...') from .asp to twisted.web.

That can also work.

But I'd also like to share data and session's state between the two. For example, to match twisted.web.server.Session with IIS session. Dunno how this could be done though.

Your best bet would be to hack something with a cookie passed between the servers, again, by using reverse proxying.

More promising (may be) but surely more complex way would be to write some kind of IIS-Twisted adapter that uses COM to talk to VB and twisted.spread to talk to Twisted.

That sounds kind of cool, and it would certainly work if you can get it up and running. Good luck with it. but-don't-get-any-on-me-l'y y'rs, -glyph