On Fri, May 17, 2013 at 12:00 AM, Dave Hylands <[email protected]> wrote: > Hi Jonas, > > ----- Original Message ----- >> From: "Jonas Sicking" <[email protected]> >> To: "Dave Hylands" <[email protected]> >> Cc: "dev-b2g" <[email protected]> >> Sent: Thursday, May 16, 2013 8:57:30 PM >> Subject: Re: [b2g] Device Storage Changes >> >> >> >> On Sat, May 11, 2013 at 2:29 AM, Dave Hylands < [email protected] >> > wrote: >> > So bug 858416 has been landed on birch and it should make its way >> > to b2g18. >> > >> > I wanted to summarize the changes that have occurred in the device >> > storage API. >> > >> > In order to support both internal and external storage areas, we've >> > added support for what I call composite device storage objects. >> > In the past a name like DCIM/car.jpg would be sufficient to >> > uniquely identify a file. However when there are multiple device >> > storage areas, this doesn't tell you which storage area the file >> > is stored in. >> > >> > So, a "fully qualified" name now looks like >> > >> > /storageName/directory/file >> > >> > While storageName looks like a directory component, it isn't, it's >> > the name of a volume. Typical volume names might be sdcard and >> > extsdcard, so a fully qualified name would look like: >> > >> > /sdcard/directory/file >> > /extsdcard/directory/file >> > >> > navigator.getDeviceStorage(type) now returns what I call a >> > composite device storage object. >> > >> > navigator.getDeviceStorages(type) returns an array of non-composite >> > storage objects. It is anticipated that this particular API would >> > only be used by the settings app for displaying free/used space >> > for each volume. Each non-composite device storage object has an >> > attribute called storageName which identifies the volume that the >> > device storage area corresponds to. >> >> Wouldn't you also need to use getDeviceStorages if you don't know >> what types of storage areas are available on the device? As is the >> case for all 3rd party apps. And might be the case for some of our >> built-in apps if we want to make their code generic and work across >> multiple devices. > > Each storage area is defined by a tuple of (type, name) > > type is one of pictures, music, videos, sdcard. > name corresponds to the physicaly storage areas, typically something like > sdcard and extsdcard. > > On a system with only one physical storage area, getDeviceStorage('pictures') > and getDeviceStorages('pictures')[0] would correspond to the same thing. > > On a device with multiple storage areas getDeviceStorages('pictures')[0] > would return a device storage area corresponding to the pictures available > from the storagename 'sdcard' and getDeviceStorages('pictures')[1] would > return a device storage area corresponding to the pictures favailable from > the storagename 'extsdcard'. > > getDeviceStorage('pictures') would correspond to a composite storage area > comprised of the pictures from both storage areas. > >> Seems like a common use case for getDeviceStorages("pictures") would >> be to enumerate all locations where pictures are stored and display >> UI to the user which explains in human understandable form where the >> various pictures are stored. >> >> Same thing when the user wanting to save a picture. The application >> would likely want to use getDeviceStorages("pictures") and display a >> human understandable picker which lets the user choose where the >> file should be saved. > > An app could do that. In our discussions from the UI people, that was > undesirable. So we added a setting to determine the name of the storage area > that would be used to save new files to. Now when you call > addNamed('DCIM/foo.jpg') and the setting is set to extsdcard, then the file > would goto /extsdcard/DCIM/foo.jpg (this name is returned in the onsuccess > method of the addNamed request). Note that the /extsdcard portion of the name > refers to a storage area by name, and it's corresponding file location might > be something like /mnt/external-sdcard.
The question isn't just "what does our own apps want to do" but also "what do we think 3rd party apps will want to do". I think we should enable apps to show in UI which pictures are located on an external card, and which are located on internal storage. Ideally without having to parse paths. I suspect this is already possible using the DeviceStorage.storageName property? And I also think we should enable applications to let users choose where a given picture should be shown, while by default selecting the one the user had picked through settings. I think the only thing we need to enable this is to have a boolean DeviceStorage.default property. >> In general I'm a bit worried about all the magic that's happening in >> the composite storage space, but I don't have any concrete proposals >> for how to get rid of it. > > There really isn't much magic. It's just a way of mapping a set of names onto > multiple storage areas. Well, from an author point of view, the other storage areas generally behave like filesystems. However the composite one "messes around" with the filenames that you provide to it. I.e. if you ask to save "DCIM/foo.jpeg" it actually saves to "/extsdcard/DCIM/foo.jpeg", while if you ask to save to "/sdcard/DCIM/bar.jpeg" it knows to not prepend "/extsdcard/", right? Likewise enumeration does things a normal filesystem doesn't. I think what we have right now is fine. The only thing I could think of to "improve" it is to remove the composite storage, which also isn't great. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
