durusmail: qp: Twisted - Was: Re: Quixote, QP, the future...?
Twisted - Was: Re: Quixote, QP, the future...?
2006-04-09
2006-04-09
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-12
2006-04-12
2006-04-13
2006-04-13
2006-04-13
2006-04-13
2006-04-14
2006-04-14
2006-04-15
2006-04-16
2006-04-16
Twisted - Was: Re: Quixote, QP, the future...?
David Binger
2006-04-10
On Apr 10, 2006, at 11:03 AM, David K. Hess wrote:

> 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?

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.

>
> 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().

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.

>
> 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.

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.



reply