On Apr 13, 2006, at 12:09 PM, David Binger wrote:

> On Apr 13, 2006, at 11:50 AM, David K. Hess wrote:
>>
>> Generally speaking, I'm not convinced that the method interface to
>> Site isn't already generic enough to be used by many types of Site
>> implementations. In fact, I think that interface should be
>> *required* of all Site implementations. If so, then bin/qp and for
>> instance bin/tqp should really only differ in one line of
>> functionality: an import statement.
>
> I'm with you up to here.
>
>> However, I also believe that the Site to use should not be chosen
>> by the management tool. That decision should be in the
>> implementation; i.e. slash.qpy.
>
> I understand what you are saying, but you haven't
> said why you believe that.  I guess you mean that you
> want bin/qp to be able to manage a collection of sites
> at the same time, each with a different Site class.
>
> The bin/qp tool expects Site.start_web() to start the
> web and scgi servers.  If I understand it correctly, you
> want your start_web() to not do that.  I don't think your
> subclass is satisfying the "contract".

Funny how two people can look at the same thing and have such a
different point of view! It looks to me like the bin/qp tool expects
Site.start_web() to "start the qp application" and Site.stop_web() to
"stop" it. It doesn't look to me like bin/qp cares how that's done.
Scgi is an implementation detail of Site.start_web() not an inherent
part of the "contract". At least that's how I see it.

The reason I believe my position above is to look at it this way. Say
I want a single installation of qp to support a Twisted application
and a default scgi application in two different sites. It seems
architecturally bad for me to be able to say "qp -s twisted_app
start" and "tqp -s non_twisted_app start". The choice of using
Twisted is more than just which web server you want to use. The code
may inherently require other twisted functionality which will break
if it isn't coordinated with the reactor.

>> Once you have made that decision, then I think moving run_web to
>> the Publisher just forces unnecessary work on the developer.
>
> This does not require anything from the developer.  The default
> Publisher provides the
> default implementation of run_web(), and this is used by the
> default implementation
> of start_web().
>
> If you want a customized run_web(), you can override.
> I'm pretty sure this is two notches simpler than writing a
> customized Site subclass that overrides start_web().
>
>> start_web in the customized site already knows all the details of
>> what needs to be done to start a twisted web application. Also,
>> making this choice conveniently gets rid of the issue of start_web
>> in the Site and run_web in the Publisher both needing to
>> coordinate whether or not to behave as a standalone application.
>>
>> So, here's what I've got working. I changed get_sites to the
>> following:
>>
>>     def get_sites(klass):
>>         """() -> {name:str : site:Site}
>>         Note that this is a method of the class.
>>         It returns an index of all of the installed sites.
>>         """
>>         sites_package= import_object(klass.sites_package_name)
>>         sites_directory = sites_package.__path__[0]
>>         names = [name
>>                  for name in listdir(sites_directory)
>>                  if (isdir(join(sites_directory, name))
>>                      and '.' not in name)]
>>         sites = {}
>>         for name in names:
>>             m = import_object("%s.%s.slash" %
>> (klass.sites_package_name, name))
>>             if hasattr(m, "Site"):
>>                 sites[name] = m.Site(name)
>>             else:
>>                 sites[name] = Site(name)
>>
>>         return sites
>>
>> And I have this in slash.qpy:
>>
>> .....
>> from qp.hub.twistedhub import TwistedSite
>>
>> Site = TwistedSite
>>
>> class SitePublisher (Publisher):
>>
>>     configuration = dict(
>>         http_address=('', 8001),
>>         )
>> .....
>>
>> I also have a suitable twistedhub.py which has a TwistedSite class
>> with just one method so far: a twisted specific start_web. I still
>> have more integration and cleanup to do, but this basic approach
>> is working. At least "bin/qp -s echo start" works and the demo is
>> reachable from a web browser.
>
> I don't think, though, that your "bin/tqp -v" does what I want it to.

bin/tqp? I don't have a bin/tqp. Assuming you mean bin/qp, yes, "bin/
qp -v" does not work correctly yet with a TwistedSite because I'm not
finished yet. I still need to reimplement Site.status() and all the
other methods that bin/qp accesses on Site.

> But, the good news is that your "bin/tqp" has the behavior *you* want.

I'm not sure what you mean. I haven't changed any code in bin/qp nor
created a bin/tqp.

Dave