Idea: Awaking Zope to Life
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: ueck@net-labs.de http://www.net-labs.de
On Sunday 13 October 2002 17: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 ..
I really need something like that for OpenFlow.
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 ??
No, but we can explore that together.
What do you think about that ?? Really interesting, I`m interested in helping you for that.
Bye, Vincenzo.
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: ueck@net-labs.de http://www.net-labs.de
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
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: ueck@net-labs.de http://www.net-labs.de
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.
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: ueck@net-labs.de http://www.net-labs.de
On Sun, 2002-10-13 at 09: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 ??
Here is my two cents ... I'd like to see Zope ship with ZEO, and by defaalt use it. To put the value in this, it could ship with a separate process pre-configured to connect to the same ZEO server (which would all be in one start up script to keep it simple), and provide a means to do scheduling outside of Zope, but inside do to the ZEO connection. Then, you could use the ZMI/custom interface for managing the thing, whilst a fully separate process runs the actual machinery of doing things in a "time"ly fashion. Fully internal, no, but combined with what you propose might well make it very well integrated. -- Bill Anderson Linux in Boise Club http://www.libc.org Amateurs built the Ark, professionals built the Titanic. Amateurs build Linux, professionals build Windows(tm).
participants (5)
-
Bill Anderson -
Chris McDonough -
Leonardo Rochael Almeida -
Ulrich Eck -
Vincenzo Di Somma