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/m
ediacontent.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> 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