On Apr 13, 2006, at 3:30 PM, David Binger wrote:
> The Site class as it is now in my tree (with Publisher.run_web())
> supports twisted or not,
> or any other web server on a per-site basis.  The only thing it
> does not support
> directly is sites that don't really want run_web() to actually run
> the application.

I see three use cases for using Twisted and QP together:

1) Use of Twisted's web server
2) Use of Twisted's other protocol support from QP
3) Embedding QP in a Twisted application

It seems to me that case 1) has little or no value. QP's SCGI
implementation looks to be a much better performing alternative.
Regardless, the Site class does (will) support that quite well via
Publisher.run_web().

Case 2) is more interesting as you can trigger Twisted activity from
inside Publisher activity, such as triggering an asynchronous SMTP
email transaction. The Site class supports that fine also. However,
this case must *always* be run with a Twisted web server, or, at
least one that coordinates with the Twisted reactor. Otherwise, none
of the Twisted activity will function correctly. It cannot be used
with SCGI (at least until the SCGI solution coordinates with the
twisted reactor on the worker side).

Case 3) I think represents a new application for QP; e.g. the HTML
management interface on a SOHO router. The Site class does not
support this and is in fact slightly hostile towards it. I need to
change many of the assumptions that Site makes about the operating
environment and how Site constructs it. I can imagine that this would
also be true for anybody else trying to embed QP in any other
application environment. Like case 2), this case also *requires* a
Twisted web server; it cannot use SCGI due to the blocking nature of
SCGI workers.

Site is not the appropriate implementation for all cases. Is there
any interest in providing a clean and supported way of choosing
different but reusable Site functionality?

Dave