Re: [Zope-dev] Idea: Awaking Zope to Life
Hi Chris, thanks for your hint .. You may also be interested in http://cvs.zope.org/Products/Scheduler/ (it has a dependency on http://cvs.zope.org/Products/Event/ and a Zope = than 2.6b1). It relies on an external clock process to tickle it every so often, but you could of course kick off a Zope thread to do this... I have looked over the sources. this Product avoids much of the trouble through calling from an external-xmlrpc-source .. that behaves like a normal http-request (auth, contexts, threading,...) I think i want a higher resolution timer with less overhead (main-loop). .. I will explore this territory during the next weeks .. thanks Ulrich Eck net-labs Systemhaus GmbH Ebersberger Str. 46 85570 Markt Schwaben fon: +49-8121-4747-11 fax: +49-8121-4747-77 email: [EMAIL PROTECTED] http://www.net-labs.de ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Awaking Zope to Life
On Sun, 2002-10-13 at 13:44, Ulrich Eck wrote: Hi there, I just had an Idea and want to hear your comments on the following: Zope is a Request-Based System. It has no internal scheduling functions except one installs Xron. I have written a MicroThread Scheduler using python2.2 generators that supply cooperative Multithreading. Now the point: I want to integrate this Scheduler as one Thread (like Xron) to Zope as Service where clients could register a callback with parameters which are called regularly with a certain priority. [...] What are the pitfalls i can run into, when trying to implement this ?? I could think of concurrency issues, problem with threads, context, security .. any concrete hints ?? Check your transaction boundaries. One of the reasons that most solutions are based on an external request is that the Zope request handler starts a transaction in the begining of the request and commits it at the end (or rolls it back if there's an exception). What do you think about that ?? Nice idea. It certainly opens a lot of possibilities (and maybe a huge can of worms :-). Hope you can pull it off :-) -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Awaking Zope to Life
Hi Leonardo, Check your transaction boundaries. One of the reasons that most solutions are based on an external request is that the Zope request handler starts a transaction in the begining of the request and commits it at the end (or rolls it back if there's an exception). this is basically done by get_transaction().begin/commit/rollback + cleanup per executed MicroThread. We have played a lot with Zope-Transactions I think this is manageable .. Thanks for the Hint :) Nice idea. It certainly opens a lot of possibilities (and maybe a huge can of worms :-). Hope you can pull it off :-) Thats one of the points I could think of too .. to really make all this work, one must probably simulate different users, that run the processes and plug into the security-machinery .. I haven't explored this in detail yet. thank for your reply Ulrich Eck net-labs Systemhaus GmbH Ebersberger Str. 46 85570 Markt Schwaben fon: +49-8121-4747-11 fax: +49-8121-4747-77 email: [EMAIL PROTECTED] http://www.net-labs.de ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Awaking Zope to Life
Ulrich, You may also be interested in http://cvs.zope.org/Products/Scheduler/ (it has a dependency on http://cvs.zope.org/Products/Event/ and a Zope = than 2.6b1). It relies on an external clock process to tickle it every so often, but you could of course kick off a Zope thread to do this... - C On Sun, 2002-10-13 at 11:44, Ulrich Eck wrote: Hi there, I just had an Idea and want to hear your comments on the following: Zope is a Request-Based System. It has no internal scheduling functions except one installs Xron. I have written a MicroThread Scheduler using python2.2 generators that supply cooperative Multithreading. Now the point: I want to integrate this Scheduler as one Thread (like Xron) to Zope as Service where clients could register a callback with parameters which are called regularly with a certain priority. Zope's Persistent Object Database would morph to an completely persistent Program that handles requests too. One could use it to implement better Workflow capabilities, or an Event Sytem (a client would register a Thread that checks for incoming messages and handles them). Many more things could be done .. What are the pitfalls i can run into, when trying to implement this ?? I could think of concurrency issues, problem with threads, context, security .. any concrete hints ?? What do you think about that ?? Ulrich Eck net-labs Systemhaus GmbH Ebersberger Str. 46 85570 Markt Schwaben fon: +49-8121-4747-11 fax: +49-8121-4747-77 email: [EMAIL PROTECTED] http://www.net-labs.de ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
