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?

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?

- refactor so that as much code as possbile is shared between and


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 ;-)

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

the main() program, if it has a zodb configuration, would register such a factory that would talk to the DB; others could do SQL or whatever).

Yeah, this is exactly what I'm after :-)



Simplistix - Content Management, Zope & Python Consulting
Zope3-dev mailing list

Reply via email to