On Apr 14, 2006, at 10:04 AM, David K. Hess wrote:

>
> On Apr 13, 2006, at 3:30 PM, David Binger wrote:
>> The Site class as it is now in my tree (with Publisher.run_web())
>> supports twisted or not,
>> or any other web server on a per-site basis.  The only thing it
>> does not support
>> directly is sites that don't really want run_web() to actually run
>> the application.
>
> I see three use cases for using Twisted and QP together:
>
> 1) Use of Twisted's web server
> 2) Use of Twisted's other protocol support from QP
> 3) Embedding QP in a Twisted application
>
> It seems to me that case 1) has little or no value. QP's SCGI
> implementation looks to be a much better performing alternative.
> Regardless, the Site class does (will) support that quite well via
> Publisher.run_web().
>
> Case 2) is more interesting as you can trigger Twisted activity
> from inside Publisher activity, such as triggering an asynchronous
> SMTP email transaction. The Site class supports that fine also.
> However, this case must *always* be run with a Twisted web server,
> or, at least one that coordinates with the Twisted reactor.
> Otherwise, none of the Twisted activity will function correctly. It
> cannot be used with SCGI (at least until the SCGI solution
> coordinates with the twisted reactor on the worker side).
>
> Case 3) I think represents a new application for QP; e.g. the HTML
> management interface on a SOHO router. The Site class does not
> support this and is in fact slightly hostile towards it. I need to
> change many of the assumptions that Site makes about the operating
> environment and how Site constructs it. I can imagine that this
> would also be true for anybody else trying to embed QP in any other
> application environment. Like case 2), this case also *requires* a
> Twisted web server; it cannot use SCGI due to the blocking nature
> of SCGI workers.
>
> Site is not the appropriate implementation for all cases. Is there
> any interest in providing a clean and supported way of choosing
> different but reusable Site functionality?

Interesting.   I certainly agree that Site is not the appropriate
implementation for all cases, and it doesn't bother me at all for
people to work on subclasses or complete substitutes as case 3,
at least, would apparently require.  I think the main thing we
are talking about here is the get_sites() function.

We *could* change get_sites(), as I think you suggested, to use the
Site class
in the qp.sites.foo.slash module, or the usual Site class if
no Site is defined there.  That would provide the flexibility you
desire.  The cost would be that there is more to explain about
what get_sites() does, and it offers a tantalizing and (I think)
dangerous
path to new users.  Also, I'm pretty sure that there will be users
that like some aspects of QP, but that find the whole qp.sites.* pattern
intolerable.  For them, they may not want a different Site class
for each Site, but they will want a Site class that finds the sites some
completely different way.   They would really want to have direct
control of the get_sites() function, not the individual site's Site
implementations.

So it seems like the ultimate "hook", for controlling all aspects of
site identification and Site classes used, is the get_sites() function.
Where should the get_sites() function you like be "configured"?
I'm thinking it should be in your customized equivalent of the bin/qp
script.

[I'd be interested to know more details about the obstacles in the
current
Site class for case 3.]