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.
> > When using the composite device storage object, If you call
> > AddNamed and were to specify "DCIM/foo.jpg" then it will use the
> > default storage area (set by the user in the settings app under
> > Media Storage).
> >
> > The onsuccess method will be passed the fully qualified name of the
> > object (i.e. you'd probably get back something like
> > /sdcard/DCIM/foo.jpg).
> >
> > Enumerate has changed slightly as well. Previously if you called
> > enumerate('DCIM') you'd get back just the portion of the filename
> > below the DCIM directory (so just foo.jpg). Now, you always get
> > back a fully qualified location (/sdcard/DCIM/foo.jpg). When you
> > use enumerate on the composite device storage object, it will
> > return all of the files on all of the storage areas.
>
> What will enumerate("DCIM") do on the composite device storage
> object? Will it return all files of the pattern "/*/DCIM/...", i.e.
> all files starting with "/sdcard/DCIM" and "/extsdcard/DCIM", or
> will it return nothing since all composite filenames start with
> either "/extsdcard/DCIM/" or "/sdcard/DCIM/"?
It will return all files which match DCIM/... from each storage area. If you
had sdcard and extsdcard then you would get
/sdcard/DCIM/...
/extsdcard/DCIM/...
So, if the sdcard had DCIM/img1.jpg and DCIM/img2.jpg, and the extsdcard had
DCIM/img2.jpg and DCIM/img3.jpg, then when you called enumerate('DCIM') on the
composite device, you would get back:
/sdcard/DCIM/img1.jpg
/sdcard/DCIM/img2.jpg
/extsdcard/DCIM/img2.jpg
/extsdcard/DCIM/img3.jpg
If you call get('/extsdcard/DCIM/img2.jpg') on the composite storage area then
it will return the DCIM/img2.jpg file from the extsdcard storage area.
(i.e. again /sdcard and /extsdcard refer to storage areas and not filesystem
names)
> 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.
Dave Hylands
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
