OK, here's the deal. The way clients implement the upload
is rather up to the clients. From my personal experience dealing with much this same request I can tell you that you
aren't going to have any fun trying to get this to work.
The best I can recommend is that you look at the javascript option of opening a second window. You're real problem will come from the fact that you have a nasty
precedence problem. When you throw up the page for the upload, you need to already know the "temp" name of the upload so that you can watch its progress. But you don't yet know it because you haven't had anything submitted. And, when you get something submitted, the window that gets the submission doesn't show it's response till after the upload is complete so once you know the temp name you can't
send the user to running display window.
The solution is to pick a "temp" name first when they go to the page and have the submit button pop a window and send the file (I suppose with javascript, somehow). Alternately, you can interpose an entire exchange where when the user hits the submit button, a javascript send with the file name happens, starts the watcher window then actually submits the file.
Any way you look at it, ugly ugly ugly and browser dependent to boot. Worse, you take the chance of making it completely unusable to people without JS or with JS
turned off.
Covering your six points quickly:
- HEAD: Try it but it doesn't solve your problem anyway.
Most clients won't actually let a form send a HEAD request, anyway.
- HTTP/1.1 sure it has capabilities but not ones you can get at through the client. The client already knows all you need, size of file and how much it has sent. Only the TCP/IP stack knows for a while how much has been ACK'ed though. That is why most clients don't bother. Even FTP clients are a little wonky on upload.
- Apache and CGI.pm already know what you need, your problem is getting the messages sorted out in the right order. After you start the upload you can't send messages back until you finish and you can't start watching easily until you start uploading...
- Combine. Javascript and a couple of perl scripts are all you need to do it but as I said you have a nasty communications order problem.
- "Outside the box?" Yeah, submit a patch to the Mozilla project so they implement a built-into-the-client upload bar. Or have the user use FTP (Perhaps fire up a onetime FTP on a special port with Net::FTP? That might be sexy.
There would be a second confirmation box pop up in there though. Maybe write an entire browser in perl so you could add fancy upload progress bars easily.
- Already done? The closest I've seen to what you want is Blogger.com's "hold on while I ftp to your site" javascript.
That is just for seeing if a process on the SERVER finishes.
It works, mostly, but it doesn't have your communication issue.
As to the post about TCL on the mailing list, that wasn't what you were looking for. That was a browser plug-in
that gets the browser to do the work while the upload happens. It is effectively a browser upgrade so you would have to encourage your users to get and install a plug-in that changes how their client displays uploads. That is fixing the client, not a CGI fix.
--
$you = new YOU;
honk() if $you->love(perl)
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
