Some other methods in Site appear dependent on start_web's
implementation, e.g. is_web_running. It seems that functionality
would also need to be moved over to the Publisher?

Using this approach, I assume I'd override those methods in my
SitePublisher class (or add a TwistedPublisher to the distribution)
with the functionality in twisted_server.py.

You mention "start the reactor". While I agree that is the general
use case, in my situation, I need QP to *not* start the reactor as I
already control that elsewhere in my application. That implies that
bin/qp is not used for controlling my twisted Publisher. Instead, my
application would find the correct Site itself and then call the
start/stop web/durus methods along with managing the entry and exit
to reactor.run().

Perhaps if a TwistedPublisher were to become part of the
distribution, it should have a disable-able call to reactor.run()
built into its run_web method. This would make bin/qp work for the
more general case but still allow me to move the reactor control
elsewhere.

Dave


On Apr 10, 2006, at 6:23 AM, David Binger wrote:

>
> On Apr 9, 2006, at 11:08 PM, David K. Hess wrote:
>> It seems that the porting effort would be minimal. However, the
>> desire to reuse the start_durus method in the Site class makes me
>> wonder if it shouldn't have tighter integration there; maybe a
>> subclass with an overridden start_web method?
>
> Maybe.  It seems like one might want different web server setups for
> different sites.  Maybe Site.start_web() should just be changed to
> call a
> run_web() method on the site's publisher.  In the case of a twisted
> site, I think the run_web() could just setup and start the reactor.