On Apr 14, 2006, at 12:38 PM, David Binger wrote:
> 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.

I'm definitely not stuck on the particular solution I posted. It was
just a quick way to test out replacing Site.

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

Perhaps a bin/*qp should just provide its own implementation of the
get_sites() functionality?

Does this imply that qp and tqp not only can, but should should have
different places where they store their sites? While case 1) sites
can be used with any type of web server, a case 2) QP+Twisted
application started with an SCGI web server will fail to function
correctly.

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

So usually, decentralization in a web app occurs in parallel
processing by HTTP servers and centralization reoccurs at the
database, right? In my case, the centralization point is not a
database but a single server process. Additionally, I have no need
for high performance (I'll usually only have one user accessing this
and then only occasionally). And I have a very strong desire for a
nice, simple solution.

My difficulties with Site stem from the assumption that QP should be
a managed child process (beginning with the fork() call in
Site.start_web and including pidfiles and kill() calls). I'm trying
to add to my server process an HTML interface that presents status
information and the ability to control features of the server. I need
to programmatically start QP when my server starts and I'd be forced
to use an IPC mechanism back to my application from my QP handlers if
QP was fork()'d into another process. Instead, I want a single
process (i.e. a single CPython instance) so that my QP handlers can
just reach over into my application's internals to easily accomplish
what is needed.

If Site's behavior were to become compatible with this use case, then
I believe I could meet my needs with just Publisher.run_web.
Otherwise, I need to develop a way to change Site's behavior while
reusing as much of the existing Site implementation as possible.

Dave