Martijn Pieters wrote:
On 5/8/07, David Pratt <[EMAIL PROTECTED]> wrote:
Hi. I know there must be a few folks that would like to easily add other
clients or servers to zope (at or after bootstrapping) and have control
over the services with the running reactor :-) A simple api for
accessing the multiservice after bootstrapping would make zope more
accessible to twisted development.
I'll say it again: I have had no need to access the multiservice. A
multiservice is nothing but a container that makes it convenient to
start and stop multiple services. The services themselves directly
contact the reactor, they do not depend on a multiservice for this.
The reactor is a singleton, you can import it yourself too to access
it's API if you need it's services.
Hi Martijn. Thanks again for your reply. I do understand the
multiservice, however I feel is a shame that configure information in my
zope.conf for any of the built-in server types would not result in my
having control over these services following bootstrapping. It does not
need to be this way. :-(
In my case, I subclassed ZopeTCPServer, but that's a subclass of
twisted.application.internet.TCPServer, and all it adds is a hook to
log the service startup in the event log. I also use a dedicated
threadpool of 1 thread for the debug server, but that's a application
requirement, services use the reactor threadpool directly otherwise.
Just hold onto the services you create, and start and stop them at
will directly. Subscribe to the Zope ProcessStarting event to start
your services at Zope startup time, and use the twisted reactor
system event triggers to hook into the shutdown. You could even create
your own multiservice object to manage your own services in one go.
I acknowledge that this is not a prerequisite to twisted development in
zope. I am working with twisted as it is. My apologies if it seems that
I have communicated it this way. It would add convenience to facilitate
methods on the services in a single service container for the instance
as a whole. I should be able to obtain from my instance what services it
is currently running, give me an iterator of the services, check the
status of any service generally, start this service, stop that service,
add this one or drop that other one. This is better in my view - it
would also provide simple infrastructure for integration for applications.
I have written clients and servers in twisted, the main difference being
that I am configuring in zope.conf and constucting buildouts to automate
I want twisted and zope to be better partners for applications. At the
present time, I am adding some additional twisted functionality to zope
as opposed to simply adding another service to my application - in way
where the control of services for the instance is managed centrally.
This is how an application should work and how it could work. Perhaps
the best way to do this is an api since I will not be the first or last
person to want to build applications with multiple services that you
will want to control and monitor.
I believe a services api could provide this more generally - whether a
zope application uses zserver or other server flavor for that matter. At
the present time services cannot be assembled concretely with central
control in an application which is disappointing to me. I guess thats
what my experience is telling me about this - though I am more focused
on using twisted in zope. Many thanks.
Zope3-dev mailing list