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 )
