Richard Lynch 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.
Yes, I want that also. Really, I want the feature to exist in the PHP
language regardless of how I intend to use it. That's the beauty of a
programming language vs a program. I want the tools to be able to build
what I want however I might want it at the time.
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!
Agreed. I SHOULD not NEED this feature. Other server-side languages
exist, so I technically don't NEED PHP either. I don't really want to
debate whether this feature should exist or not, but it seems to me that
the replies I've gotten from this list so far suggest that internals of
PHP development are seriously opposed to such a feature? I am more
interested in which project extensions are leading in momentum to solve
the problem I am trying to solve and not blaming other projects
(browsers) for not building the feature first.
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.
The back-and-forth you refer to is termed 'polling'. With a protocol
like HTTP, polling is really the only option unless I implement a socket
server which is capable of sending events. This is something I may be
building into the project also, but aside from HOW I move the
server-side collect data back to a web client, that is independent of
needing to collect the information on the server side in a format which
can be accessed and read easily.
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.
You'd need a battery of meters, for all running processes, or at least
all the ones currently in file upload state.
I would like to have a list of all file uploads in progress, yes. A
semi-frequently updated snapshot of the information I defined would be
sufficient. If a callback function is invoked periodically it would be
equivalent to firing an event and would allow a php program to log the
data to a common data repository which could be ready by another process
on the system.
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"
Right. Under the callback method example, I would have access to
$_SESSION which would already contain enough information about the
logged in account for my purposes. This is trivial.
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.
The POST method sets the Content-length, right. So, PHP must trust that
the browsers are not lying. For security purposes we don't need to
worry about whether this number is wrong because it is only for
display. Processing uploaded files does not occur until the file
completes uploading.
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, ... you could write a tool to watch /tmp for
files and get a list of the /tmp names being uploaded.
Yes, this is simple.
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...
Yes. Using Linux. This will work.
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.
This will not work. And this is exactly WHY an extention/patch is
needed. Between the time PHP choses a /tmp file name and the time the
upload is completed, there is not execution of PHP code. Therefor, we
don't know the /tmp name assigned to an upload until AFTER the upload is
completed and then it's too late.
You're not going to get ... accuracy ...
It won't be so hot for tracking who's uploading what in real-time,
It should be. Using the patch, I already have this working. I now want
a cleaner, supported solution which doesn't involve a custom patch which
will not be supported in the future. Although the patch I am using
works, it was build for PHP 5.0.3 RC1 and since I am using 5.1.2 you can
understand my concerns that it will fail to continue working when the
switch is made to PHP 5.2 or PHP 6.0.
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.
Passing this from the client form is insecure and can not be trusted.
Declaring callback functions needs to remain a server-side declaration
either through code or an INI setting, etc.
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.
My original email was searching for advice on which project has momentum
and what the current state of any discussions about the issue were.
Does anybody have information on the PEAR package which appears to be vapor?
http://pecl.php.net/package/postparser
I see the name Curt Zirzow, but no contact information for that "author".
Is there not a package which has been adopted by the community or does
every developer share Richard's opinion that this feature doesn't belong
in PHP?
Dante
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
