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


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


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to