I think I am missing something very basic in my understanding of
how SWFUpload (& uploading via flash in general) works. I can't seem to find a simple explanation. Does this script by-pass php.ini restrictions on file size etc.. and does it perform better than a PHP-based uploading application?
If I'm using, lets say the Drupal integration of this, is the actual uploading
happening via php or Flash? I'm seeing a lot of threads on this forum re: problems with php.ini, if this is an alternative to php uploading functionality then why does this still apply? In what instances will the php processor bottleneck flash up-loading?
I don't mind php.ini's file-size restrictions, just don't like the speed and performance issues with php upload forms.
2 sides to every story
There are always 2 parts in a file transfer. Sender and Receiver.
The sender is usually the browser and the receiver the webserver (which channels it to PHP).
But the browser doesn't give us very much control over the upload. So we've built SWFUpload which uses Flash as the sender. The receiver stays the same.
So, now we have more options as the sender (stop uploads, get progress, ajax style uploads) but the receiving (Server) stays much the same. You have to manage PHP.INI settings, have a server side script to receive and process the upload, etc.
There are methods that add all the functionally to the server. Usually they are more complicated. You have to install special scripts on the server for tracking upload progress and then from the browser periodically poll the server for progress information.
Using a client side approach with flash much of that work is pushed to the browser and very little additional work is required on the server side. If it weren't for several bugs in the Flash Player you could get away with almost no changes on the server side.
-------
Is the upload via flash or PHP: Both. Flash sends the file to the web server which receives it and lets PHP process the upload.
What bottlenecks are there: The upload is nearly identical to a standard HTTP upload done by the browser. The performance should be the same.
If you are having trouble with upload speed it is probably not related to PHP. More likely it's related to your ISP connection speed and your servers hardware.
making more sense now
I guess what I was hoping for was something akin to the client based Java-applets out there (several on sourceforge) that completely bypass http protocol & allows users to upload via ftp protocol within their browser.
Java obviously makes things way harder for CMS integration, but this is a holy grail "wish-module" for Drupal users! SMFupload better than a white-screen and hourglass though!!
I think when uploading images using a Drupal CMS you sometimes hit PHP's built in image processing, and updating nodes etc.. so that might be more the problem at times. On the same server, Ftp seems 10x quicker than Drupals uploading to me!
One thing, when you say "have a server side script to receive and process the upload, etc." any resource/documentation links you can send me on that?
Demos
Every demo and the upload.php in the Samples package. But a framework will handle or wrap file uploading in a different way. So you'll have to refer to your framework's documentation on handling HTTP uploads.