On Tue, April 25, 2006 9:55 pm, D. Dante Lorenso wrote: > Richard Lynch wrote: > that > the replies I've gotten from this list so far suggest that internals > of > PHP development are seriously opposed to such a feature? They may or may not be opposed to attempting to use server-side technology to provide client-side statistical data, for a file that the CLIENT is uploading. Which is why I suggested that the request for server-side statistical tracking of uploads in progress for the server-side statistical analysis would be a Good Thing to propose. > 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 momentum, as far as I know, of all the project extensions to do what you describe is zero (0). > 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. Gah! I know what it's called. Let's try AGAIN. You want to use POLLING from server to client to measure how much data the client has sent. Does not the CLIENT already *KNOW* how much data it sent? Why in the world would you generate all that traffic to compute data already in existence on the client in the first place? That is the fundamental problem to which objections are raised on this issue. It's just plain daft to poll the server to find out how much data you sent it, when you're the one sending the data. > 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. If it's trivial, code up the patch and send it. >> 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. Oh but there *IS* execution of all kinds of PHP code between that time -- Just not in the script that is receiving the file. Since you're building a statistical monitoring of the process, I'm suggesting that you have ANOTHER PHP script running to examine the state of /tmp and monitor the progress from "outside" the script actually receiving the file. It won't be pretty, but it can be done with what's available in PHP today, without patches. >> 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. If you submit a similar patch, and specifically label it as server-side statistical analysis feature for uploaded files in progress, I SUSPECT it has a much better chance of "going" than a server-side hack to solve a client-side problem. >> 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. You're right. That would be a gaping security hole. >> 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". He posted a few zillion messages here in PHP-General... His email has to be in the Marc archives. > 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? AFAIK, no package has achieved any kind of wide-spread acceptance, or even anything more than a niche acceptance. Once again, since you've missed it in previous posts: I happen to think that having SERVER-SIDE introspection for in-progress file uploads would be a Good Thing. I just think it's daft to use it with polling for CLIENT-SIDE progress meters, since the CLIENT already HAS that data, and should expose it via an API for something JavaScript or other client-side processing. The nice thing is, once you have the hooks you want for server-side, it's a pretty trivial exercise to do the polling and client-side you want. And if you think I somehow represent the PHP Dev Team and their thinking, then you're REALLY off-target... :-) It is only MY opinion that your proposal will have a much greater chance of success if you drop all references to client-side uses of the feature, and lobby for it solely on the merits of server-side feature-set. -- 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
