[Zope3-dev] Re: zope.app.twisted.main?

[Philipp von Weitershausen]

On 2 Feb 2007, at 18:15 , Chris Withers wrote:
> Philipp von Weitershausen wrote:
>> As Jim pointed out in an earlier discussion [1], we would rather  
>> like to separate server configuration from the application  
>> definition (ZODB, logs, etc.).
>
> That sounds like any work I do here will help...
>
>>> - make twisted/zserver interchangeable through a zope.conf setting
>> Like Jim, I would rather like to see (at least the HTTP) server  
>> definition thru something that's more general, such as paste.deploy.
>
> I don't know paste.deploy and I don't have time or inclination to  
> learn it. However, any work I do will be aiming to make it simpler  
> to slot in different bits in different roles. What does  
> paste.deploy do?

It's a generic system that binds a WSGI application (such as the  
zope.publisher) to a WSGI server (such as twisted.web2 or  
zope.server). You can also register WSGI middlewares inbetween. See  
http://pythonpaste.org/deploy/. Other Python web frameworks use it or  
can at least use it. One of the big advantages of paste.deploy is the  
easy definition of middlewares. Paste itself is a large library of  
WSGI middlewares which features things like a funky live JavaScript  
exception debugging middleware (the application raises an error and  
the browser gets the full traceback, incl. a "command line" which  
allows you to debug the code TTW, see http://mrtopf.blip.tv/file/ 
47128/).

Perhaps there's not a need for that separation in the Zope 3 core  
with packages like zope.paste around...

> I was toying with the idea of trying to have an IConfiguration  
> utility such that ZConfig could be switched out, is that what  
> you're talking about?

Not sure. Note that ZCML hasn't been loaded yet when main() is  
executed and the application configuration is read.

I thik we can stick with ZConfig for now, even though Jim doesn't  
like it... *wink* ;)

>>> - refactor so that as much code as possbile is shared between  
>>> zope.app.twisted.main and zope.app.server.main
>> +1
>> I'd say that this should result in a general main() program that  
>> *can* (but doesn't have to) read the application definition from a  
>> zope.conf file,
>
> Indeed.
>
>> and does server setup (at least HTTP) through a general framework  
>> like paste.deploy.
>
> Well, I'll try and make this code encapsulated...
>
>> I would assume that this also results in a separate configuration  
>> file for paste.
>
> Yay! More config files, just what we need ;-)

Well, if we'd use ConfigParser style config files for our application  
definition, we could use one configuration file -- the one that  
paste.deploy also uses...

>>> - explore ways of seperating some of the publication concerns
>> +1
>> For one, I suggest factoring the whole root object issue out of  
>> the publication (e.g. introduce an IRootObjectFactory utility  
>> that, when called, will return the root object;
>
> How about just making an IApplication utility, or is IApplication  
> too specific?

What *is* an "Application"? Sounds like a Zope2ism to me (the root  
folder being called "application").

Yes, the publication in Zope 3 (which was written at an very early  
stage with a lot of Zope 2 background) has a method "getApplication",  
but all it does is return the root object. So let's reflect that name  
in the utility.

It just occurred to me that we could make those IRootObjectFactory  
things named utilities. Then you cna register as many of them at the  
same time and just choose which one you want using a switch in, say,  
zope.conf.

Philipp