On Apr 10, 2006, at 12:36 PM, David K. Hess wrote:

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

Understood.  If you are not using the qp tool for site management,
though, then there is no need to for you to call the Site.start_web()
method.  You can just call your function that configures your
reactor the way you want it.

>
>> 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 don't see any need for your code to call Site.get_sites().
Don't you just have one site to take care of?
Just say "x=Site('mysite'); x.start_durus(); prepare_reactor(x)"
where prepare_reactor() calls methods on x to get the server
addresses it needs.


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

Yes.  That's what I would do.  The run_web() method would mostly be for
applications that want the qp tool to manage web services in a
nonstandard
way.

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

That path gets tangled pretty quickly.
The Site class is what qp depends on to find slash.py.

If anyone wants all of their apps to run with a different Site class, I
think they should change the import in (a copy of) the bin/qp file.

If anyone really wants a particular QP publisher to run with a
different site class,
then I'd suggest putting "self.site.__class__ = MySiteClass" in the
SitePublisher.__init__().