Web 2.0 isn't so without a new file upload February 8, 2007
In writing a web application, I've always found it a pain that no matter how advanced of an interface you try to make, the file upload mechanism is so archaic. This functionality is built into every web browser. It's a text box with a "browse..." button next to it. Upgrading this functionality is the last step, probably, in getting to Web 2.0.
When writing a news post or anything of the sort, where you can include images inline, personally, with my software, I'd have to upload the images before I even attempt to write the news. One way around this is to be able to drag an image from a folder on your computer inline to the document. This works but not as expected. The image shows for you because the URL of that image is pointing to the file on YOUR computer. If you were to save that news and review it, it would look great to anyone who viewed it from your computer, but to anyone else, they'd see the big X placeholders for missing images.
I've read a technical article on including the actual content of the image inside the "src" attribute of the "img" tag. It's the bytes encoded in base64. That makes download times pretty big for an HTML website. This behavior isn't available in the previous example, because javascript can't read the contents of a file on the computer, an that would be the only way you could achieve it in real time. Another downside is that images encoded this way only work in Mozilla and possibly a few other browser, definitely not anything Microsoft based.
Another option would be to upgrade the standard. The W3 standard about how files are uploaded to a website. If I could drag an image, like my example of editing a news post, from a folder on my computer into the text of the news, and have a way that it automatically, and asynchronously, uploads that file to the website, and instead displaying the one on my computer, it displays, after a short delay, the one that's physically located on the server... for lack of a better term, that'd be @#%#@$ sweet. Technically, that would take some pretty complex changes.
Technically, I imagine the only way to accomplish this feat is allowing access to the contents of that file in Javascript. Not to say that when you download a website, Javascript in the website can just access any file on your computer, but when you drag a file onto the web page, a Javascript event is called with the contents (and other specs) of that file. This is a client feature, it would have to be implemented in Javascript. So that cuts out any browsers that a) don't support Javascript, and b) don't have an asynchronous way to make requests to a server (the 'AJ' in "Ajax").
For all I know, the W3 is working on something like this. Right now, there's no way to get this functionality, aside from writing a client app wholly separated from your website code. This is a pain because what do you write it in? With the heterogeneous environment of client computers... there's Java, but still, the whole idea of having to write an app to achieve this functionality is a bad idea, and the way websites do it right now is flawed.
There's nothing Web 2.0 about file uploads today. Any app where you have to upload files to achieve any kind of goal for content will never feel like a desktop application until files can be dragged/dropped in real time. Or pasted for that matter. I'll take anything.