Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
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. 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. -- Martijn Pieters ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
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. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
Martijn Pieters wrote: On 5/8/07, David Pratt [EMAIL PROTECTED] 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
On 5/8/07, David Pratt [EMAIL PROTECTED] wrote: 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. For which you'd need to expose the root multiservice to start with, of course. -- Martijn Pieters ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
Martijn Pieters wrote: On 5/8/07, David Pratt [EMAIL PROTECTED] wrote: 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. For which you'd need to expose the root multiservice to start with, of course. Yes, absolutely :-) Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
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. Has anyone got any ideas on incorporating this. I have made a suggestion but hoping for input and other ideas to make this happen. The ZopeService class subclasses service.Multiservice. The Multiservice itself provides methods from twisted for adding, disowning, starting or stopping services or iterating over the services in the multiservice. I am hoping we can can come up with a good way to make this object accessible within zope. Many thanks. Regards, David David Pratt wrote: I am wondering if as part of bootstrapping zope, that a utility could not be set up in the site manager that could hang on the zope multiservice object. Methods available for the utility could allow you access to this after booting zope. Is this reasonable? Many thanks. Regards, David David Pratt wrote: Hi Martijn. Many thanks for your reply. I was not aware of your project so it is quite nice to see. I am hoping to try it out. :-) At zope's startup, a multiservice is started that currently adds the servers setup in the zope.conf. I have created configuration for additional clients and servers to use the existing thread pool and currently adding them to the multiservice using a modified main.py By having access to the multiservice object, you have complete control of each service in the app as well as the ability to incorporate other services to an already running reactor. Interaction within the app using multiple reactors is not safe - so access to this object allows you to add, remove, start or stop services. I also want the configuration to be explicit - so to using zconfig and recipes. Overall, I am integrating apps into buildouts as well. It is useful to be explicit here too since your configuration will otherwise be in a single egg somewhere. This could make it awkward to run multiple servers performing the same task on a machine, which is the pattern I am working with. Regards, David Martijn Pieters wrote: On 5/3/07, David Pratt [EMAIL PROTECTED] wrote: Hi. I'm really wanting to do more with twisted in zope. One thing that would make this much easier is to have a means of getting hold of the twisted multiservice following startup as opposed to using a different main.py (as I have been) to allow the other services to be added, started or stopped at, or any time following startup. I am not sure what you are looking for, but I have no trouble starting additional services after Zope startup. See my Wing IDE integration for Zope3, for example; http://trac.zopatista.com/zopatista/browser/z3wingdbg/trunk/ It starts additional services, such as a single-threaded HTTP debug server on a separate port, either at Zope start or later as the user requests. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
I am wondering if as part of bootstrapping zope, that a utility could not be set up in the site manager that could hang on the zope multiservice object. Methods available for the utility could allow you access to this after booting zope. Is this reasonable? Many thanks. Regards, David David Pratt wrote: Hi Martijn. Many thanks for your reply. I was not aware of your project so it is quite nice to see. I am hoping to try it out. :-) At zope's startup, a multiservice is started that currently adds the servers setup in the zope.conf. I have created configuration for additional clients and servers to use the existing thread pool and currently adding them to the multiservice using a modified main.py By having access to the multiservice object, you have complete control of each service in the app as well as the ability to incorporate other services to an already running reactor. Interaction within the app using multiple reactors is not safe - so access to this object allows you to add, remove, start or stop services. I also want the configuration to be explicit - so to using zconfig and recipes. Overall, I am integrating apps into buildouts as well. It is useful to be explicit here too since your configuration will otherwise be in a single egg somewhere. This could make it awkward to run multiple servers performing the same task on a machine, which is the pattern I am working with. Regards, David Martijn Pieters wrote: On 5/3/07, David Pratt [EMAIL PROTECTED] wrote: Hi. I'm really wanting to do more with twisted in zope. One thing that would make this much easier is to have a means of getting hold of the twisted multiservice following startup as opposed to using a different main.py (as I have been) to allow the other services to be added, started or stopped at, or any time following startup. I am not sure what you are looking for, but I have no trouble starting additional services after Zope startup. See my Wing IDE integration for Zope3, for example; http://trac.zopatista.com/zopatista/browser/z3wingdbg/trunk/ It starts additional services, such as a single-threaded HTTP debug server on a separate port, either at Zope start or later as the user requests. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
On 5/3/07, David Pratt [EMAIL PROTECTED] wrote: Hi. I'm really wanting to do more with twisted in zope. One thing that would make this much easier is to have a means of getting hold of the twisted multiservice following startup as opposed to using a different main.py (as I have been) to allow the other services to be added, started or stopped at, or any time following startup. I am not sure what you are looking for, but I have no trouble starting additional services after Zope startup. See my Wing IDE integration for Zope3, for example; http://trac.zopatista.com/zopatista/browser/z3wingdbg/trunk/ It starts additional services, such as a single-threaded HTTP debug server on a separate port, either at Zope start or later as the user requests. -- Martijn Pieters ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
Hi Martijn. Many thanks for your reply. I was not aware of your project so it is quite nice to see. I am hoping to try it out. :-) At zope's startup, a multiservice is started that currently adds the servers setup in the zope.conf. I have created configuration for additional clients and servers to use the existing thread pool and currently adding them to the multiservice using a modified main.py By having access to the multiservice object, you have complete control of each service in the app as well as the ability to incorporate other services to an already running reactor. Interaction within the app using multiple reactors is not safe - so access to this object allows you to add, remove, start or stop services. I also want the configuration to be explicit - so to using zconfig and recipes. Overall, I am integrating apps into buildouts as well. It is useful to be explicit here too since your configuration will otherwise be in a single egg somewhere. This could make it awkward to run multiple servers performing the same task on a machine, which is the pattern I am working with. Regards, David Martijn Pieters wrote: On 5/3/07, David Pratt [EMAIL PROTECTED] wrote: Hi. I'm really wanting to do more with twisted in zope. One thing that would make this much easier is to have a means of getting hold of the twisted multiservice following startup as opposed to using a different main.py (as I have been) to allow the other services to be added, started or stopped at, or any time following startup. I am not sure what you are looking for, but I have no trouble starting additional services after Zope startup. See my Wing IDE integration for Zope3, for example; http://trac.zopatista.com/zopatista/browser/z3wingdbg/trunk/ It starts additional services, such as a single-threaded HTTP debug server on a separate port, either at Zope start or later as the user requests. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
