The new file reading stuff in HTML5 is fantastic- I've written a little JS widget for my site that takes a local video file, reads the first 100KB of it, then sends that off to a remote video processor by cross-domain AJAX to get a thumbnail, which is then loaded onto the user's page.

It really is amazing what you can do. The only thing missing is being able to decode video metadata so that I know whether 100KB is too little or too much to send if I want to extract a single frame.

you could use broadway, which is a h.264 player written in js onto canvas to get your frame and then just send that. see: http://badassjs.com/post/12035631618/broadway-an-h-264-decod... http://mbebenita.github.com/Broadway/broadway.html

That is an extremely cool project. Unfortunately, we don't know what format users are uploading, so we have to pass it off to an ffmpeg-powered service.

oh well in that case there still is no need to just send 100k and hope it works, you could use websockets to push it to the service, pipe it directly into ffmpg and when you get back a frame have websocket tell browser to stop sending data.

you can do the same thing with 2 ajax requests too. one doing the upload and the other that opens a connection at the same time and waits for a success response. onreadystate 3 of the second request, abort() the upload request.

When you say cross-domain AJAX, do you mean JSONP or proxying, or is there another technique I'm not aware of?

Apologies for veering off topic a bit...

Does have experience with the CORS "partial support" in IE?

[http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing]

My first thoughts go to security concerns, but I didn't see any mention of them in the article. Does anyone have any links that deal with this?

This is really cool stuff, so my first instinct is to consider the possible caveats.

Well, you always have to manually select the file(s). At that point, the website could always upload it, so this is no worse than the status quo.

There isn't any, really- I was surprised.

I had exactly the same thoughts really.

Any way to request access to a folder to read all the local files in it?

http://www.html5rocks.com/en/tutorials/file/filesystem/ i think you can't request, but once user selects directory, you can read files under it. you'll enjoy this.

The spec changes quiet often and if you do the javascript file stuff alot (my startup deals with local files with javascript so i use js for files alot) you will come across something that has been changed from what it is on html5rocks. It gets ugly very quickly. When i started it, the condition was alot worse, there was practically no one writing any tutorials. Your only option was to reverse engineer the spec draft. That wasn't pretty. Now the condition is much better (but i would still love to see more people write tutorials about this). This is very powerful stuff and not many people are writing about it, maybe because some parts of filesystem interaction spec are still not stable and used my many people.

I've found the same thing. I'm holding off on implementing some of this stuff (outside of prototypes) because it seems Safari/IE support is missing and there isn't a decent polyfill that I'm aware of.

hmm there is not much to hold ground on any browser other than chrome. Filesystem api wasn't stable the last i checked in FF. Any public implementation that runs on atleast 4 major browser is still atleast 6 month away :( My app is in chrome webstore so i don't have to worry about browser support and chrome also updates automatically so if it works in latest stable, i can launch without thinking twice :)

Does anyone know of a browser plugin or anything that allows you to write files, too?

well you can always use file system api. http://www.html5rocks.com/en/tutorials/file/filesystem/ but its chrome only

For what it's worth, TiddlyWiki can save itself on the filesystem even with Firefox (user gets prompted to allow access). I don't know how it works though and when I tried it seemed to be quite buggy.

According to Wikipedia they use FileI/O, a Mozilla API for accessing the filesystem, which from what I can tell it's more directed at Addons than webpages.

What about security? I assume its not possible to read and write arbitrary files in the fs?

From parent's link:

If you're calling requestFileSystem() for the first time, new storage is created for your app. It's important to remember that this file system is sandboxed, meaning one web app cannot access another app's files. This also means you cannot read/write files to an arbitrary folder on the user's hard drive (for example My Pictures, My Documents, etc.).

Thank you for pointing it out. I assumed it would be like this but didn't find it scanning the page.

I have used this for a few things. One of them that was the most interesting to code, even though very narrowly useful, was a way to compare two memory dumps from a C++ game to find the objects that don't match (after the game detects a checksum mismatch between online players, the players are asked to make these dumps, and then submit them to us; We drag'n'drop two dumps into a webpage and get a printout of objects that don't match). Admittedly a C++ app would have been a lot faster, but Chrome still managed to read the dumps and extract the relevant info in several seconds.

i used this some time ago for a chrome app https://chrome.google.com/webstore/detail/ednbfblokipkbkecmf... it's open source here https://github.com/franzenzenhofer/farbzauber