RE: Device Storage API

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] 
Sent: Wednesday, May 30, 2012 8:38 AM
To: Frederick Hirsch
Cc: 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>
To: public-device-apis@w3.org
Cc: "Frederick Hirsch" <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 Friday, 1 June 2012 13:00:40 UTC