[Zope] Progress information for long running process

[Jan Maska]

Yeah, right. :-)
This was just a quickly made-up trick. It obviously *IS* a nonsense to use
it on operations that may take ages (as those 30 minutes before you go home
:-)))
I'd recommend it though, for operations that take from a minute to - let's
say ten minutes.
I believe everyone's pleased with knowing exactly what's going on behind the
Zope walls. :-)

Furthermore, it could eventualy report a problem during the operation.
If well-thought, it could really supply an almost-interactive interface.
For example: your operation consists of two or more iterations. In the first
one it gathers needed data and in the second it feeds them to an important
repository, sends them by email to your boss's boss or interacts with a
remote API.
Now, imagine the operation didn't get valid data. That's not a failure of
the script, thus it doesn't die().
Using this technique, it can pause the process and require an interaction
from you..
" This and that happened. Do you want to:
a) Abort, b) Restart the process c) Continue anyway"

Which is impossible by the email.

But I admit that you'd pobably need this type of interaction is very rarely.
:-)

BTW, I like the idea of sending an ETA with administration contacts via
email.

-Mac


=================================================
My first reaction was, not pleasant.  On second thought, this is an
interesting idea.  Why?  I think that this immediatley frees up the Zope
thread, which is crucial.

Expanding on the email idea.  It is an honest one.  You are freeing up
resources doing it that way, both computer resources and people resources.

I don't like to watch progress bars that take 30 minutes to complete.

More importantly, that progress bar is tying up a browser window on the
client, probably a zope thread, and probably a bunch of other things
I don't know about.  This sounds like a batch process.  Trying to make
it appear to be interactive is probably a waste of everyones time.

The user probably cares about the following:
1)  knowing that the task was submitted
2)  knowing that he will be told when the task is done, and how to get
    it.
and
3)  knowing what to do if the task seems to be taking too long, that is,
    how long too long is, and who to call if no email is forthcoming.
    [this should be a part of the submission email.]

The user probably does not care to know 'I am at step 39 of 100, the
renormalization phase'.

If it is important to the user to know this kind of information, or the
users demand it, then do all the RESPONSE stuff.  Otherwise, avoid it.
The email idea is one way of avoiding the whole mess.

The redirect to logfile is also interesting; it appears to have many
of the same benefits as the email idea.  The only detriment is that
the client has to keep the browser open to see that the job is
completed, and maybe even to see the job results.

Jim Penny