[Catalyst] Detecting if a user aborted a (long) download

Wade.Stuart at fallon.com Wade.Stuart at fallon.com
Mon Mar 12 20:42:26 GMT 2007







> Wade.Stuart at fallon.com wrote:
> >
> >
> >
> >> Since we haven't heard from the OP. I have two questions:
> >> o Did you investigate sendfile?
> >>
> >
> > Sendfile() buys you nothing relevant to the OP's question.
> >
> Really? The OP was merely detecting whether or not the session aborted,
> not whether or not the file successfully downloaded. Apparently
> sendfile() can return an error condition related to the OP's original
> design.

The point is it does not.  Welcome to the Internet where AOL's (google,
netspeed, isp X with SpeedupPro tech, or that silly corporate office) proxy
server/firewall/virus proxy has just soaked up the full download (no
sendfile or io dispatcher error) and the client only got half.  The OP's
assumption and initial implementation is obviously broke.  Handing him a
Jack to fix his airplane wing he is describing as a flat tire is a
disservice.



> >
> >> o Have you considered implementing a download progress indicator? One
of
> >> the reasons users give up on downloads is that they don't know what's
> >> happening.
> >>
> >
> > What browser are you using that does not:
> >
> > 1, have its own download session manager + progress display
> > 2, where download app continues download even if you leave the
page/site
> > that started it
> > 3, and the browser tells you "hey numbnuts, you are still downloading
are
> > you sure you want to close?" when you try to close your browser before
the
> > download is complete.
> > 4, where a separate download progress bar that is non standard would be
> > anything but confusing to a user?
> >
> > The bottom line is, downloads break sometimes for many reasons.  Your
app
> > (being on the server) will never be able to know if the download
completes
> > or not unless you control the download end-to-end (such as writing and
> > distributing your own download manager).  A silly progress bar embedded
in
> > your webapp does not get you past this problem.  A simple, smart and
quite
> > frankly the industry standard solution is to allow the user to try
again on
> > failure.
> >
> It's not clear to me that the OP is using a browser, vs. some custom
> application that relies on HTTP protocol. Since the OP hasn't chimed in
> on this thread, I'm done answering these questions.

We were told enough information to know that the implementation was broken
and we are offering valid (unbroken or not-so-broke) alternatives.  And as
another poster said:  The advice is free -- take it or leave it.





More information about the Catalyst mailing list