[Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]

Christopher N. Deckard cnd@ecn.purdue.edu
Thu, 29 Aug 2002 06:20:28 -0500


On Thu, 29 Aug 2002 11:41:44 +0100, Chris Withers spoke forth:

> -------- Original Message --------
> Subject: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs
> Date: 29 Aug 2002 14:36:30 +0800
> From: Tim Hoffman <timhoffman@cams.wa.gov.au>
>
> If my ZODB is so big that it takes half an hour to rebuild, I
> would hate it to be aborted just because the browser lost it's
> connection (ie IE crashed ;-)
> 
> or running a big import. I don't need the browser to hang around
> for the end result, I just want it to complete at some point. (ie
> kicking off long running processes through xml-rpc, I don't want
> to keep the connection open for the duration.)

This brings up a question I've always had, is it possible to "fork"
a request into the background.  Your example being an import, is it
possible to set up the import script to do the following:

  * User requests that some import file be imported
  * Zope makes sure it's a valid import file (extension or whatever
    it does, basically that it exists)
  * Zope forks the import off into the background
  * Zope responds to the request saying "The import is in progress,
    blahdy blahdy blah."  

Meanwhile, the user gets instant feedback that his import is going,
and doesn't have to wait for the browser to say anything, or time
out, whichever comes first.

I think this would be very useful if one were writing something
like an order processing system, where you wanted to build the
order processing into Zope.  Someone adds junk to their "shopping
cart", clicks the "send me my junk" button, and gets instant
feedback telling him that the order is being processed.

I can think of lots of uses for that kind of thing.  

Oh, and back on the original topic, does anyone know for sure if
the browsers actually send something to the server when "stop" is
pressed?

> Either you can programatically look at the state of the connection
> (within the process and chose to kill it) or there was a console
> tool so that you could see long running threads and kill them.

A console tool for managing threads would be great.  Being able to
kill off a request, like one of our users hitting the undo or
history tab, would be nice, until we get a patch going for that. 
Some things just take way too long.

-Chris