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

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

Reply via email to