On Tue, April 25, 2006 5:28 pm, D. Dante Lorenso wrote: > Richard Lynch wrote: >> On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote: >> Anything you see with "PHP" "upload progress meter" together has to >> be >> some kind of hack whose under-pinning is NOT PHP at all, but is >> JavaScript or similar client-side technology. >> > > Not true. The graphical display is HTML, DHTML, JavaScript, etc...but > the means of monitoring the progress from the server side MUST be done > with PHP. I'm sorry. Your original post sounded (to me) like you wanted a progress meter on the browser (client-side) for the user to see their files uploaded. AFAIK, all the tools you referenced were written with that purpose in mind. Presumably even the worst browsers have some concept of how large the file is, and how many bytes have been sent to the server. So you certainly DO NOT need server-side information to implement a client-side progress meter of the progress of a file upload! > The code that I have seen so far requires hooks into PHP > which execute callback functions periodically in order to update the > progress of uploaded files as PHP processes input. Yes, which is a silly place to try and "fix" this for client-side progress meters, as you then generate traffic back-and-forth from the client to measure the number of bytes received, instead of the browser just measuring bytes sent. > browser in all cases. From the server side, I need to be able to > monitor > > * who is currently uploading files, > * which files are being uploaded, > * how big are the files being uploaded, > * how much time has passed since upload began, and > * what percentage of those files is completed > > I do not need to return this data to a client at all times. Sometimes > I > just want to use the data system administration, analysis, and > tracking. The most popular need would be for returning the > information > to the client, however, as you suggest. In this case, a "meter" isn't going to cut it... You'd need a battery of meters, for all running processes, or at least all the ones currently in file upload state. You'd also need tie-ins to your login/authentication to determin "who is uploading files" as the only answer inherent to PHP is "the User set in httpd.conf" Which files are being uploaded would presumably display both the original name as sent by the browser, which is not something one can trust for anything useful, and the /tmp name. How big they are relies on the browser sending the correct Content-length: for the upload. I don't know how often they get it right, but I'm betting that are some pretty common errors in this area that PHP corrects for already. So your meters would not be accurate in some (hopefully few) cases. While I can see where this might be a useful tool to have server-side, I can suggest several possible ways to implement some portions of it without hacking PHP source. First, it's a pretty safe bet that PHP uses a common prefix on the files being uploaded. So you could write a tool to watch /tmp for files and get a list of the /tmp names being uploaded. That would at least tell you how many files are currently in upload status. Using filectime and filemtime would tell you the timing info -- Though Windows will suck (as usual) as it only tracks to the nearest minute or something... For tying the filenames back to the users who are logged in, you'd have to have an onClick() on the submit button which would send some kind of information (filename, filesize, user) to a PHP script that would log the upload about to begin in a database. The onClick would then return false so that the normal form submission process would kick in. You would then have to use heuristics about the file timing to "guess" which files were most likely which -- though you could probably get pretty accurate about that part, especially if you are willing to code it so that completed uploads tie back in and eliminate incorrect guesses. You're not going to get the level of accuracy you'd have with hacked PHP source, but you can get enough accuracy for statistical analysis. It won't be so hot for tracking who's uploading what in real-time, due to the guessing part -- but after the upload finishes your information will be as accurate as it can be with hacked source. Another option is to provide patch to PHP which gives a special INPUT parameter to a FORM that can be used to provide a callback file to load, and a callback function within that file to call, and then modify the file upload routine to load and call that function. It seems genuinely useful enough to this naive reader, and should not cause an undue burden for those who don't use it. Check with PHP-Dev to see if such a patch is likely to be accepted before putting in TOO much time on it. HTH >> Why don't you ask the guys who write BROWSERS why *they* don't >> provide >> a nice API/interface to display progress, or, better yet, why the >> browser itself doesn't just do it once and for all for everybody? >> > That is a good idea, and I will recommend it for future solutions. For > short term, that is not the focus of this email. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
