Philipp von Weitershausen wrote:
As Jim pointed out in an earlier discussion , we would rather like to
separate server configuration from the application definition (ZODB,
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
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
and does server setup (at least HTTP) through a general framework
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
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