[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 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. :-(
> 
> Right, it seems I misunderstood. You want to be able to control
> services not created by you, but by the existing codebase in
> zope.app.twisted. That is a very legit usecase. :)

Hi Martijn. Yes, in fact I would like want control over all services in 
the app but it is currently impossible the way it is now without some 
hacking. I don't want to do that.

> I hadn't thought of that angle, this sounds like something worthy of
> putting into the Zope3 bugtracker. Registering the multiservice as a
> utility would solve this usecase.

I'll put this in the bugtracker as you have suggested. I think this 
would be a good short term solution. A better long term solution being a 
services API that could be used generically. There was some talk of 
using paste for configuring servers so at the least I am hoping that 
when this is considered that controlling services within zope be given a 
fair chance also. Services should be able to be turned on and off using 
application logic - and the app itself should be able to tell you 
something about its services and their state.

> 
>> 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.
> 
> Right, access to the multiservice would give you that, it is an iterator.
> 

For sure. Many thanks.

Regards,
David