On Apr 10, 2006, at 10:39 AM, David Binger wrote:
> I was thinking of changing the run_web(self) call in start_web()
> to "get_publisher().run_web()".  This lets the Publisher do
> whatever it wants to do to get http/scgi or whatever running,
> while preserving the basic start-stop/pidfile functionality of
> the "qp" command line tool.  I'd rather not move start_web()
> itself to the Publisher if we can help it.

My concern is that I already handle forking and pidfile management
elsewhere so I need that behavior in start_web factored out. In my
case QP is not the application, just a feature of another application.

> If you are not using the qp script for controlling the publisher, then
> you have an easy way to direct your site-control to your custom
> Site subclass,
> with start_web() doing what you need to tell the reactor about your
> application.  That seems like a reasonable way to get your job done.
>
> Note that you can call the start/stop durus methods from your
> own script without changing anything.

Given my concern above, this might be a better approach. Though, the
Site.get_sites interface might need to be touched since it explicitly
doles out Site objects.

> I think it would be nice to have a function like this:
>
> def get_reactor(site):
>     """
>     Return a twisted reactor configured for this site.
>     """
>
> This could be used in a SitePublisher.run_web() implementation that
> may or may not call run().  It could also be used directly in
> other scripts that start twisted servers for QP sites.
>
> I don't think a TwistedPublisher subclass is necessary.

I guess the beauty of adding run_web to the Publisher is that people
have ready access to overriding it. But if I have to subclass Site
anyway to change as much behavior as I need to, perhaps I'm better
off encapsulating all of the twisted stuff over there?

Does this make the case for a Site subclass instantiated from slash.py?

Dave