> What I'd like is some scheme that lets me issue a
> "now downloading your file" HTML page *and then*
> return the contents of StaticFile like:
>
> ...
>
> But I think this constitutes two replies to one request
> and assumes HTTP keeps request state?
>
> How do Quixote users handle this kind of requirement in
> practice?  I can see one way would be to have separate
> URLs for the message and the download and have the
> message HTML do a  "refresh" call back to the download
> URL?
>
> Cheers,
>
> Stu
>


Stu,

This (as you observed) isn't really a Quixote specific issue.  This would be
somewhat tricky with any web solution I'm familiar with.

Personally, I'd approach it the way you outlined:
.../bar/filename.zip/requisition  <-- figures out if it's available, and
either returns 'not available' or returns 'please wait', with a refresh
(doesn't have to be a meta... Qx makes it easy to do the real thing) to the
next url (.../bar/filename.zip) that actually serves the StaticFile.

Something along these lines:

class filenameUI(object):
     _q_exports = ['requisition']
     def __init__(self, filename):
         self.filename = filename
         self.can_publish = can_publish(self.filename)
         self.stage = ""

     def requisition(self, request):
         if self.can_publish:
             url = "../%s" % url_quote(self.filename)
             # That may need to be a full qualified url... I don't remember.
             # What we're looking for is ".../bar/filename.zip"
             request.response.set_header('refresh','5,url=' + url)
             return """Your file will be transmitted momentarily...

                    If it doesn't start, please click
                    here.""" % url
         else:
             return "Sorry, that file not available"


     def _q_index(self, request):
         if self.can_publish:
             the_file = StaticFile(self.filename)
             return the_file(request)
         else:
             return "Sorry, that file not available"

     __call__ = _q_index



That said, some browsers can deal with documents being sent in a fragmented
form that is spread out over time, but, a) Qx isn't put together in a way
that would accomodate this easily, if at all (it requires that the server be
able to send 'part' of a reply, then sit on it's thumbs for a time, then
send some more, than sit on it's thumbs... etc until complete.  Qx is
designed around the idea that the reply isn't sent until the whole reply is
ready.  Further, I doubt you could change the content-type in the middle of
the reply even with a browser that would honor this 'trick'.  But am not
sure about that.  This trick could be used to provide a choppy form of
animation... Sorta like a slide show.  I've never tried it personally, but
saw a demo in something once...  I think it was the jsp engine that was
installed with Oracle, but even that's fuzzy.


HTH,

Jason