RE: Media Access/Device Storage/Gallery API

Hi Jungkee,

I have looked at your Web Intents based Gallery API and tested the demo. It works fine for the simple use case of picking a  media file and displaying it's metadata. Just a question, why do you exclude your Gallery API from picking local media files? Couldn't a user agent's implementation of the Gallery API provide access to local media galleries?

Best regards
  Claes


From: Jungkee Song [mailto:jungkee.song@samsung.com]
Sent: den 31 maj 2012 12:39
To: 'Steve VanDeBogart'; 'Doug Turner'; public-device-apis@w3.org; public-sysapps@w3.org
Cc: 'Doug Turner'; public-web-intents@w3.org
Subject: RE: Media Access/Device Storage/Gallery API

Thanks Steve. Thanks Doug. I looked at your proposals.
Here are a few discussion points that I would like to bring to the table, actually to all the members:

1. Requirements
  - Locating media storages
  - Searching media items (filtering and ordering by given metadata)
  - Exposing and modifying metadata

In order to provide media related capabilities to apps, I think the media item searching and the metadata manipulation are required functionalities. In this sense, although Device Storage API gives good level of abstraction and simplicity, it might not cover some of the necessary use cases. In that, I am sort of leaning on [1] and [3] approaches more.

2. Scope
  (A) local storage (including external usb device, etc.)
  (B) remote media resource (clouds)

(A) seems to be apparent [1][2][3].
For (B), I suppose it is a very useful use case to pick remote media resource in the cloud-based eco. However, it would not be feasible to make one perfect API to resolve all the details.

Having it considered, my intention was to recast the Gallery API in DAP a fairly simple one using Web Intents (to cover case B) and work on more powerful one in the new group, SysApps (for case A).

I would like to hear your opinion.

Here is my demo on (B)[4]: http://jungkees.github.com/gallery

3. Working Groups
  - DAP (Gallery)
  - SysApps (Media Storage)

As mentioned in 2, we have two grounds to move this topic forward. Let's talk about the direction.


[1] Media Content: https://developer.tizen.org/help/topic/org.tizen.help.web.api.device/tizen/mediacontent.html
[2] Device Storage: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI
[3] Media File Systems: http://goo.gl/L8zXT
[4] Gallery draft (DAP): https://dvcs.w3.org/hg/dap/raw-file/16185b62381d/gallery/index.html

Regards,
Jungkee

From: Steve VanDeBogart [mailto:vandebo@google.com]
Sent: Thursday, May 31, 2012 7:20 AM
To: Doug Turner
Cc: Jungkee Song; Doug Turner; public-device-apis@w3.org
Subject: Re: Media Access/Device Storage/Gallery API

On Wed, May 30, 2012 at 1:48 PM, Doug Turner <dougt@mozilla.com<mailto: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<mailto:vandebo@google.com>>
To: public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Cc: "Jungkee Song" <jungkees@gmail.com<mailto:jungkees@gmail.com>>, "Doug Turner" <doug.turner@gmail.com<mailto: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