RE: Device Storage API

Response inline.

Thanks,
Bryan Sullivan 

From: Steve VanDeBogart [mailto:vandebo@google.com] 
Sent: Monday, June 04, 2012 1:12 PM
To: SULLIVAN, BRYAN L
Cc: Doug Turner; Frederick Hirsch; public-device-apis@w3.org
Subject: Re: Device Storage API


On Fri, Jun 1, 2012 at 9:44 PM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
Comment inline.

Thanks,
Bryan Sullivan
On Jun 1, 2012, at 4:07 PM, "Steve VanDeBogart" <vandebo@google.com<mailto:vandebo@google.com>> wrote:

inline...
On Fri, Jun 1, 2012 at 12:27 PM, SULLIVAN, BRYAN L <bs3131@att.com<mailto:bs3131@att.com>> wrote:
Comment inline.

Thanks,
Bryan Sullivan
From: Steve VanDeBogart [mailto:vandebo@google.com<mailto:vandebo@google.com>]
Sent: Friday, June 01, 2012 12:01 PM
To: SULLIVAN, BRYAN L
Cc: Doug Turner; Frederick Hirsch; public-device-apis@w3.org<mailto:public-device-apis@w3.org>

Subject: Re: Device Storage API

I certainly can understand the appeal of separating different media types into different virtual containers, especially in the mobile context where file storage is generally abstracted away from the user. However, in the desktop environment I think it will end up confusing the users. If the user stores their pictures and videos from a particular event in a folder then when viewed through this kind of API those items get pulled apart into two different hierarchies. I prefer to preserve the user's organization system to minimize the user's confusion.

<bryan> I believe in most cases the app would choose the storage abstraction that makes sense for the media type, and if there are options, perhaps present them to the user e.g. the option to store visual media in "pictures" or "videos". The other options are to defer all storage decisions to the UA (e.g. based upon media type: too limiting) or to the user (e.g. based upon their explicit choice or selection of specific filesystem locations: too intrusive, difficult, and inconsistent in constrained devices). There is a balance in letting the app use abstractions and still offer the user the ability as appropriate to select the preferred abstraction.

For storing of new media, I certainly would defer to the application, it will probably do what the user directs it to do.  But for media that already exists on the platform the app and UA don't necessarily have any input into how it is structured.  Consider a photo bug's desktop; the user will certainly have devised an organizational scheme for pictures (and video) e.g. My Pictures\2012\May\15\SF Trip\Wharf\
<Bryan> Agreed. Further, we used the well-known names in WAC only as a way to resolve the applicable local file system root, under which the normal file system API operations can be used, e.g. allowing the app to create a subdirectory structure per the user's preference or app needs. In supporting this concept for this Device Storage API I was not assuming that all structure under the abstract name is deferred to the UA to manage; I think that many users will want to manage the structure themselves through their apps.

Ok, but my point was that we can't control what's in those directories.  The user may have both images and videos in My Pictures\2012\May\15\SF Trip\Wharf\.  So at that point which top level division do you put it in, "video" or "pictures"?  Do you duplicate the directory structure and have the pictures in one and the video in the other (my initial assumption). Or do you allow the video to live in the pictures directory, or is there some other option?  If you intend the latter, than the initial division is merely a suggestion like "My Pictures, My Videos, My Music" on windows.  In that case, it's platform specific and not enforced, so an app looking for a picture may want to look through all the directories anyway.

<Bryan> Yes, I believe these are suggestions only. The user could put a JPEG of a contract in "documents" or "pictures", and a voice note recording in "documents" or somewhere else that makes sense to the user. It's only an abstraction of the underlying filesystem location (implementation specific, and even perhaps user-specific if for example through the platform features the user has chosen a particular place to store pictures), not a request for the UA to put files where their media type (how determined?) implies. And for searching it's just a hint to apps, which can easily search all locations if the app wants to be thorough and the user permits.

--
Steve
 
--
Steve
On Fri, Jun 1, 2012 at 5:59 AM, SULLIVAN, BRYAN L <bs3131@att.com<mailto:bs3131@att.com>> wrote:
Using well-known and user-familiar abstractions such as "pictures", "music", "video", "documents", "temp", etc is a good approach. We used that in the concept of file system "roots" in the WAC FileSystem API, and it's an easy thing for developers to leverage to point right to where they want to store/access files. It's also useful in presenting options to users for those data storage functions.

Thanks,
Bryan Sullivan

-----Original Message-----
From: Doug Turner [mailto:dougt@mozilla.com<mailto:dougt@mozilla.com>]
Sent: Wednesday, May 30, 2012 8:38 AM
To: Frederick Hirsch
Cc: public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: Re: Device Storage API

right, the Device Storage API leaves it up to the implementation to define what "file systems" are backing the storage.  I say that because you could have an implementation that uses a database instead of a file system directory.  The main entry point of the API allows you to pass what storage you're interested.  Our implementation for basically maps "pictures" to where on the file system pictures exists.

----- Original Message -----
From: "Frederick Hirsch" <Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>>
To: public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Cc: "Frederick Hirsch" <Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>>
Sent: Wednesday, May 30, 2012 7:00:47 AM
Subject: Re: Device Storage API

Doug

I think it is worth discussing this Device Storage API in DAP, thanks for mentioning it.

It is in the scope of gallery, which in the charter is for  "Gallery API, an API to manage the local media file storage" (sounds similar to the Device Storage API description you gave)  http://www.w3.org/2011/07/DeviceAPICharter

Is one difference of the Device Storage API and File System API that the device storage API might be limited to a more restricted portion of the file system than the file API? (e.g. limited to a media area?)
Could this be a difference (responding to the question on the wiki page)

Thanks

regards, Frederick

Frederick Hirsch
Nokia

Received on Monday, 4 June 2012 20:26:53 UTC