Plupload is multi-runtime file uploader. Keyword here is - multi-runtime. Which means that if one runtime fails to initialize, it will try another. The problem is that runtimes are not equally backed up with the same features. Flash for example has severe problems with chunking and accessing raw file data in general. Also it cannot trigger file dialog programmatically (just like Silverlight). Additionally, Flash and Silverlight have to operate in two modes and the actual set of capabilities depends on the mode that they've been initialized into. HTML4 is the most crippled of all - it can't chunk, it can't resize the images, it can't upload binary streams, it can't even report a progress.
In most cases you do not even need to know about those complexities, but if you are planning something fancy, like extracting ID3v2 tags from MP3 files on client-side or similar, you will need a way to tell Plupload about those capabilities that you'll require, otherwise it might choose a wrong runtime.
Plupload has a number of options that are supported in one runtime, but aren't - in another (see the feature table below). But when you request them in the config, they do not affect decision-making process, by default (there are exclusions to the rule however). Instead they are considered as recommendations, so that if a runtime that is selected in the end can fulfill them, it will fulfill them. Otherwise they will be ignored. This is done to achieve the ultimate purpose - upload the file... whatever it takes.
Currently there are two operational modes: browser and client. HTML runtimes (HTML5 and HTML4) operate in browser mode only, so additional mode is only for third party shims - Flash and Silverlight.
The whole necessity of introducing additional operational mode arose from the fact that features may be or may not be supported, depending on the way you initialize the runtime. In the table
1. Not effective on files over 200mb (the whole file should be preloaded in memory first).
2. Progress is estimated - browser mode in Flash has multiple benefits, and only two real drawbacks, although quite huge ones. The first one is [1] and second is inability to report upload progress. So we approximate it.
3. Seems essential, but not supported in iOS5 or less (upload is simply not possible there).
4. Only in Chrome 11+. It should be mentioned though that this feature requires separate file picker, since the same control cannot pick up files and folders simultaneously. It has to be one or the other.
5. In general this feature is available in every modern environment, but sometimes, usually due to unexpected bugs, it has to be disabled. Like in iOS and Safari on Windows.
6. IE can trigger file dialog programmatically but fails to upload selected file to an iframe, resulting into an Access Denied error.
7. Reliably files can be filtered only after selection. There are multiple problems with the file dialog.
8. Features are supported or unsupported depending on the environment, but in generally it is usually safer to assume them - unsupported.
9. Only text and document, and additionally - json (if window.JSON is defined).
10. Only 200 and 404.
11. Only GET and POST.
12. Only for POST requests.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4