On Apr 10, 2006, at 4:56 PM, David Binger wrote:
>
> On Apr 10, 2006, at 4:01 PM, David K. Hess wrote:
>
>> How about a combination of both approaches? I would create
>> TwistedSite which is a subclass of Site. TwistedSite would have a
>> standalone() method that defaults to returning True which results
>> in a reactor.run() call when start_web is invoked and results in
>> overall "QP is the application" behavior. Combined with the
>> __class__ hook you suggest above, this makes the general twisted
>> case manageable from bin/qp and very simple for users to accomplish.
>
> I think run_web() should just do what the name implies.
> Having an additional not-really switch doesn't seem
> clearer to me.

Ah, I was assuming not adding run_web to the Publisher class in my
description above and just handling all of the twisted stuff in
TwistedSite. My thinking was that with run_web I would still need
knowledge of what it intends to do over in TwistedSite so that
TwistedSite can bypass standalone behavior like forking and pidfile
management.

Perhaps I shouldn't be conflating the two issues. In other words, go
ahead and do the twisted setup and optional reactor.run() call from
run_web in the SitePublisher and add a defaulted argument to
start_web in the TwistedSite class that allows me to disable the fork
and pidfile behavior?

> I think we have a way to handle the general case, and a
> way to handle your unusual case, so it seems like we should
> be happy.

Yep, I like the feel of how this would work.

Dave