- From: Doug Turner <dougt@mozilla.com>
- Date: Wed, 30 May 2012 13:48:53 -0700 (PDT)
- To: Steve VanDeBogart <vandebo@google.com>
- Cc: Jungkee Song <jungkees@gmail.com>, Doug Turner <doug.turner@gmail.com>, public-device-apis@w3.org
Thanks Steve. I looked at yours and found that it does alot more than we needed. Basically, we needed a hash to a list of file/blobs. Maybe there is some way we can make these two system work together? For example, Metadata could easily be some property off of DOMFile, right? ----- Original Message ----- From: "Steve VanDeBogart" <vandebo@google.com> To: public-device-apis@w3.org Cc: "Jungkee Song" <jungkees@gmail.com>, "Doug Turner" <doug.turner@gmail.com> Sent: Wednesday, May 30, 2012 11:22:25 AM Subject: Media Access/Device Storage/Gallery API Since there have now been two media access APIs posted here, I wanted to point out the one I posted to the webapps group a few weeks ago: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0682.html The API is at http://goo.gl/L8zXT One big difference in this API is that it uses the FileSystem API. In my opinion, there are a couple advantage of this approach. Using an existing API makes it easier for web developers to pick up and integrate with the rest of the web platform. Also, the FileSystem API is fairly complete - enumeration, addition, removal, etc in both async and sync flavors - whereas a separate system would probably add all those pieces in the long run. And even though the FileSystem API is used, the backend for that API in the media case could be anything, a directory (or set of directories), a database, or even an extension that provides access to a user's online media. It'd be great to talk about bringing these APIs together. -- Steve
Received on Wednesday, 30 May 2012 20:49:22 UTC