Re: Media Access/Device Storage/Gallery API

On Thu, May 31, 2012 at 3:39 AM, Jungkee Song <jungkee.song@samsung.com>wrote:

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

Since the Media File Systems proposal is on the list, then I agree.  But
seriously, I think that dealing with metadata (extracting, editing, and
searching) will be a useful aspect of the interface and will enable a large
variety of consumers of the API.  The Media Content API is fairly similar
to an earlier version of the Media File System API - before the file system
part was added.


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

I agree that B is harder. There are a few concessions toward B in the Media
File System API, enough that B seems feasible with the API.


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