If you really need handle an arbitrary processing time. You might need to separate the request submission from the processing, and the processing from the results display.

Roughly the way it would work would be like dropping your laundry off at the cleaners. You bring in the dirty clothes and then get a ticket back and an expected due date. You come back around the due date. Very likely your clothes are ready and when you present the ticket you receive your clean clothes. Occasionally, you get told that due to some sort of delay your clothes aren't ready and you are given a new due date.


A similar sort of thing could be done with a long running request. The initial request gets bundled into some sort of "job" object, and a Job ID is returned and a "please wait" page. That page can have a delayed redirect to a results page which can take a job ID, determine if it is complete and display the result. Meanwhile, you have an entirely separate process (perhaps run by the Scheduler product <http://cvs.zope.org/Products/Scheduler/> that takes jobs, processes them and inserts its results.

Of course, I'm leaving off a lot of details here. Off the top of my head, I can think of the following issues that I'm just glossing over. I'm sure there are many more: You don't want job IDs to be easily guessable or forgeable, or people might be able to steal each others laundry. You have to think about what you do when jobs get abandoned, (eventually the clothing racks get full) Finally, (and thankfully one that I don't have a laundry analogy for) you may need to concern yourself with the fact that the Zope user that is doing the job processing is different than the one doing the requesting.
_______________________________________________
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to