Re: Media Access/Device Storage/Gallery API

On Wed, May 30, 2012 at 1:48 PM, Doug Turner <dougt@mozilla.com> wrote:

> 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.
>

There is some additional functionality in my API, though it's spec'd in a
way that you could have null implementations for some parts of it.
 getDeviceStorage and getMediaFileSystems are pretty similar and the
DeviceStorage class has a subset of the functionality in the FileSystem
API.  In addition my API has functionality to deal with the metadata -
extracting what's there, changing metadata, storing auxilary metadata, as
well as searching through it - and a couple utility functions.
 extractMetadata/assenbleMediaFile explicitly say that they handle the
metadata that the user agent understands, so a user agent needn't
understand a particular media type or any for that matter.  My
searchMetadata() function has some of the functionality of getDeviceStorage
- you could search for a particular media type, but you can also search on
any of the other metadata fields.  If you're storing media in a database,
it should be pretty easy to support functionality along those lines and
that functionality makes it very easy to create different ways of sifting
through media files.  Of course the utility functions are
completely negotiable, I have some good and some not so good reasons for
them.


> 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?
>

Certainly if you were to use DomFile as the entry type of an organizational
system, you could hang a metadata property off it.  However, the File class
already has size, type, mtime, and name as properties directly on the class
so it would be a bit strange to have both first class and second class
metadata.

--
Steve


> ----- 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
>