[Zope3-dev] zope.app.twisted.main and zope multiservice

[David Pratt]

Martijn Pieters wrote:
> On 5/8/07, David Pratt <fairwinds at eastlink.ca> 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.

Regards,
David