Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Device Storage Changes
110 views
Skip to first unread message
Dave Hylands
May 11, 2013, 5:29:27 AM5/11/13
to dev-b2g
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.
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.
Calling freeSpace or usedSpace on the composite object will return a sum of the free or used space over all of the volumes. Calling available on the composite object will return a composite availability.
So if any volume is available, you'll get back "available". If no volumes are available, and any are shared, then then you'll get back "shared", otherwise you'll get back "unavailable".
If you call available on a non-composite object it will return the availability for that particular storage area.
I'm sure I've broken some stuff, but the basics seem to work, i.e. I can take a picture, and see it in gallery, and I can see music etc. I'll be working next week to more exhaustively test all of the areas which I may have otherwise missed.
Dave Hylands
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.
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.
Calling freeSpace or usedSpace on the composite object will return a sum of the free or used space over all of the volumes. Calling available on the composite object will return a composite availability.
So if any volume is available, you'll get back "available". If no volumes are available, and any are shared, then then you'll get back "shared", otherwise you'll get back "unavailable".
If you call available on a non-composite object it will return the availability for that particular storage area.
I'm sure I've broken some stuff, but the basics seem to work, i.e. I can take a picture, and see it in gallery, and I can see music etc. I'll be working next week to more exhaustively test all of the areas which I may have otherwise missed.
Dave Hylands
Dave Hylands
May 11, 2013, 5:29:46 AM5/11/13
to dev-b2g
Doug Turner
May 13, 2013, 1:40:02 PM5/13/13
to dev-b2g, Dave Hylands, Jan Varga
Along with these changes, I would like to promote Dave Hylands and Jan
Varga to owners of the device storage code. I am stepping away from
this area of code due to other responsibilities. The world (or at least
this code) is a better places with these two folks at the helm.
Doug
Varga to owners of the device storage code. I am stepping away from
this area of code due to other responsibilities. The world (or at least
this code) is a better places with these two folks at the helm.
Doug
Doug Turner
May 13, 2013, 1:40:02 PM5/13/13
to dev-b2g, Dave Hylands, Jan Varga
Along with these changes, I would like to promote Dave Hylands and Jan
Varga to owners of the device storage code. I am stepping away from
this area of code due to other responsibilities. The world (or at least
this code) is a better places with these two folks at the helm.
Doug
Dave Hylands wrote:
Varga to owners of the device storage code. I am stepping away from
this area of code due to other responsibilities. The world (or at least
this code) is a better places with these two folks at the helm.
Doug
Dave Hylands wrote:
Doug Turner
May 13, 2013, 1:40:02 PM5/13/13
to dev-b2g, Dave Hylands, Jan Varga
Along with these changes, I would like to promote Dave Hylands and Jan
Varga to owners of the device storage code. I am stepping away from
this area of code due to other responsibilities. The world (or at least
this code) is a better places with these two folks at the helm.
Doug
Dave Hylands wrote:
Varga to owners of the device storage code. I am stepping away from
this area of code due to other responsibilities. The world (or at least
this code) is a better places with these two folks at the helm.
Doug
Dave Hylands wrote:
Jonas Sicking
May 16, 2013, 11:57:30 PM5/16/13
to Dave Hylands, dev-b2g
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.
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.
> 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.
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/"?
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.
/ Jonas
Dave Hylands
May 17, 2013, 3:00:48 AM5/17/13
to Jonas Sicking, dev-b2g
Hi Jonas,
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
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.
> > 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/"?
/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.
Dave Hylands
Thomas Zimmermann
May 17, 2013, 3:26:19 AM5/17/13
to Dave Hylands, dev-b2g
Hi!
> 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
Do we have standards regarding the directory part? I noticed that there
is a 'Download' directory on my unagi's sdcard, but Bluetooth currently
stores transfered files in 'download/bluetooth'.
Best regards
Thomas
>
> 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.
>
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
> 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
is a 'Download' directory on my unagi's sdcard, but Bluetooth currently
stores transfered files in 'download/bluetooth'.
Best regards
Thomas
>
> 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.
>
> 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.
>
>
> 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.
>
> Calling freeSpace or usedSpace on the composite object will return a sum of the free or used space over all of the volumes. Calling available on the composite object will return a composite availability.
>
> So if any volume is available, you'll get back "available". If no volumes are available, and any are shared, then then you'll get back "shared", otherwise you'll get back "unavailable".
>
> If you call available on a non-composite object it will return the availability for that particular storage area.
>
> I'm sure I've broken some stuff, but the basics seem to work, i.e. I can take a picture, and see it in gallery, and I can see music etc. I'll be working next week to more exhaustively test all of the areas which I may have otherwise missed.
>
> Dave Hylands
> _______________________________________________
>
> So if any volume is available, you'll get back "available". If no volumes are available, and any are shared, then then you'll get back "shared", otherwise you'll get back "unavailable".
>
> If you call available on a non-composite object it will return the availability for that particular storage area.
>
> I'm sure I've broken some stuff, but the basics seem to work, i.e. I can take a picture, and see it in gallery, and I can see music etc. I'll be working next week to more exhaustively test all of the areas which I may have otherwise missed.
>
> Dave Hylands
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
Dave Hylands
May 17, 2013, 3:43:03 AM5/17/13
to Thomas Zimmermann, dev-b2g
Hi Thomas,
----- Original Message -----
> From: "Thomas Zimmermann" <tzimm...@mozilla.com>
> To: "Dave Hylands" <dhyl...@mozilla.com>
> Cc: "dev-b2g" <dev...@lists.mozilla.org>
> Sent: Friday, May 17, 2013 12:26:19 AM
> Subject: Re: [b2g] Device Storage Changes
>
I think that it would be worthwhile being consistent on the case of the filenames, so you should file a bug.
Dave Hylands
----- Original Message -----
> From: "Thomas Zimmermann" <tzimm...@mozilla.com>
> To: "Dave Hylands" <dhyl...@mozilla.com>
> Cc: "dev-b2g" <dev...@lists.mozilla.org>
> Sent: Friday, May 17, 2013 12:26:19 AM
> Subject: Re: [b2g] Device Storage Changes
>
> Hi!
>
> > 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
> Do we have standards regarding the directory part? I noticed that
> there
> is a 'Download' directory on my unagi's sdcard, but Bluetooth
> currently
> stores transfered files in 'download/bluetooth'.
I think email may use download/email as well. The filesystem is FAT, so its case preserving, but not case sensitive. So Download/bluetooth and download/bluetooth both happen to refer to the same directory.
>
> > 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
> Do we have standards regarding the directory part? I noticed that
> there
> is a 'Download' directory on my unagi's sdcard, but Bluetooth
> currently
> stores transfered files in 'download/bluetooth'.
I think that it would be worthwhile being consistent on the case of the filenames, so you should file a bug.
Dave Hylands
Eric Chou
May 17, 2013, 3:44:01 AM5/17/13
to Thomas Zimmermann, Dave Hylands, dev-b2g
> Subject: Re: [b2g] Device Storage Changes
>
> Hi!
>
> > 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
> Do we have standards regarding the directory part? I noticed that
> there
> is a 'Download' directory on my unagi's sdcard, but Bluetooth
> currently
> stores transfered files in 'download/bluetooth'.
Actually, it's downloads/bluetooth :)
>
> Hi!
>
> > 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
> Do we have standards regarding the directory part? I noticed that
> there
> is a 'Download' directory on my unagi's sdcard, but Bluetooth
> currently
> stores transfered files in 'download/bluetooth'.
For Bluetooth module, we are happy to change the target directory since
it has been written as a fixed path in our code for a while.
>
> Best regards
> Thomas
>
Best regards,
Eric Chou
Andrew Sutherland
May 17, 2013, 5:57:48 AM5/17/13
to dev...@lists.mozilla.org
On 05/17/2013 03:43 AM, Dave Hylands wrote:
> I think email may use download/email as well. The filesystem is FAT, so its case preserving, but not case sensitive. So Download/bluetooth and download/bluetooth both happen to refer to the same directory.
E-mail currently just stashes everything in the root. (And collisions
> I think email may use download/email as well. The filesystem is FAT, so its case preserving, but not case sensitive. So Download/bluetooth and download/bluetooth both happen to refer to the same directory.
are dealt with by appending a timestamp onto the basename part of the
filename and retrying the save once, should a failure occur.)
We can do something better.
Andrew
Jonas Sicking
May 20, 2013, 4:08:14 AM5/20/13
to Dave Hylands, dev-b2g
On Fri, May 17, 2013 at 12:00 AM, Dave Hylands <dhyl...@mozilla.com> wrote:
> Hi Jonas,
"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
> Hi Jonas,
>
> ----- Original Message -----
>> From: "Jonas Sicking" <jo...@sicking.cc>
>> To: "Dave Hylands" <dhyl...@mozilla.com>
>> Cc: "dev-b2g" <dev...@lists.mozilla.org>
> ----- Original Message -----
>> From: "Jonas Sicking" <jo...@sicking.cc>
>> To: "Dave Hylands" <dhyl...@mozilla.com>
>> Cc: "dev-b2g" <dev...@lists.mozilla.org>
>> 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 < dhyl...@mozilla.com
>> > 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
>> >
>> > 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
>> >
>> > 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.
>>
>> > 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 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.
"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.
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
Dave Hylands
May 20, 2013, 11:17:33 AM5/20/13
to Jonas Sicking, dev-b2g
Hi Jonas,
...snip...
> 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.
There is nothing to stop an app from prompting the user where to store a file. There are 3 ways that an app could choose to store a file:
1 - Using the composite storage area, you could do:
storage.addNamed('/storageName/filename', blob);
and blob will be storerd on the real storage area with the name give by storageName.
2 - Using the composite storage area, you could do:
storage.addNamed('filename', blob);
and blob will be stored on the real storage area indicated by the user (in the settings app) as the default place to store new files.
3 - Using a real storage area (obtainable via getDeviceStorages), you could do:
storage.addNamed('filename', blob);
and blob will be stored on that storage area.
> >> 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 actually think that composite storage is making the multiple storage areas all look like one big file system, exactly like what would happen under linux when you mount different filesystems onto different top-most directories.
> 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.
And the UI people really didn't want the users to have think about which volume the file was stored on, which is the basic need that the composite storage device is fulfilling.
Dave Hylands
...snip...
> > 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?
Well, you could enumerate getDeviceStorages and find the storage area you were interested in (using the storageName attribute) and then do an enumerte on just the one storage area (so by using a real storage area and not using the composite storage area).
> > 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.
1 - Using the composite storage area, you could do:
storage.addNamed('/storageName/filename', blob);
and blob will be storerd on the real storage area with the name give by storageName.
2 - Using the composite storage area, you could do:
storage.addNamed('filename', blob);
and blob will be stored on the real storage area indicated by the user (in the settings app) as the default place to store new files.
3 - Using a real storage area (obtainable via getDeviceStorages), you could do:
storage.addNamed('filename', blob);
and blob will be stored on that storage area.
> >> 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.
Dave Hylands
Jonas Sicking
May 20, 2013, 4:39:18 PM5/20/13
to Dave Hylands, dev-b2g
On Mon, May 20, 2013 at 8:17 AM, Dave Hylands <dhyl...@mozilla.com> wrote:
>> 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.
>
> There is nothing to stop an app from prompting the user where to store a file. There are 3 ways that an app could choose to store a file:
>
> 1 - Using the composite storage area, you could do:
> storage.addNamed('/storageName/filename', blob);
> and blob will be storerd on the real storage area with the name give by storageName.
>
> 2 - Using the composite storage area, you could do:
> storage.addNamed('filename', blob);
> and blob will be stored on the real storage area indicated by the user (in the settings app) as the default place to store new files.
>
> 3 - Using a real storage area (obtainable via getDeviceStorages), you could do:
> storage.addNamed('filename', blob);
> and blob will be stored on that storage area.
Yup. Understood.
>> 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.
>
> There is nothing to stop an app from prompting the user where to store a file. There are 3 ways that an app could choose to store a file:
>
> 1 - Using the composite storage area, you could do:
> storage.addNamed('/storageName/filename', blob);
> and blob will be storerd on the real storage area with the name give by storageName.
>
> 2 - Using the composite storage area, you could do:
> storage.addNamed('filename', blob);
> and blob will be stored on the real storage area indicated by the user (in the settings app) as the default place to store new files.
>
> 3 - Using a real storage area (obtainable via getDeviceStorages), you could do:
> storage.addNamed('filename', blob);
> and blob will be stored on that storage area.
But what you can't do, as far as I can tell, is to create a UI which
lets the user choose which location to store a file. While also
selecting by default the storage area that the user has chosen as the
default.
What you can do, is to list all available store areas, and then in
addition to that have an option which says "default" without showing
the user any indication of where the file will be stored if "default"
is chosen.
I would think that in a good UI you'd want to just list the available
storage areas, without a separate "default" option. And by default
select the area which the user has previously indicated should be the
default. That way the user can see where the file will be stored if no
action is taken, and he/she can take action to store the file
elsewhere if desired.
I guess you could accomplish that with the current API by writing a
dummy-file to the composite storage and see where that file will get
saved. But that seems pretty hacky and could result in security
dialogs being displayed to the user.
I think a better solution would be to simply add a .default property
to DeviceStorage which is set to true for the default area, and false
for all other ones.
/ Jonas
Dave Hylands
May 20, 2013, 5:09:50 PM5/20/13
to Jonas Sicking, dev-b2g
Hi Jonas,
----- Original Message -----
> From: "Jonas Sicking" <jo...@sicking.cc>
> To: "Dave Hylands" <dhyl...@mozilla.com>
> Cc: "dev-b2g" <dev...@lists.mozilla.org>
> Sent: Monday, May 20, 2013 1:39:18 PM
> Subject: Re: [b2g] Device Storage Changes
>
----- Original Message -----
> From: "Jonas Sicking" <jo...@sicking.cc>
> To: "Dave Hylands" <dhyl...@mozilla.com>
> Cc: "dev-b2g" <dev...@lists.mozilla.org>
> Sent: Monday, May 20, 2013 1:39:18 PM
> Subject: Re: [b2g] Device Storage Changes
>
> What you can do, is to list all available store areas, and then in
> addition to that have an option which says "default" without showing
> the user any indication of where the file will be stored if "default"
> is chosen.
>
> I would think that in a good UI you'd want to just list the available
> storage areas, without a separate "default" option. And by default
> select the area which the user has previously indicated should be the
> default. That way the user can see where the file will be stored if
> no
> action is taken, and he/she can take action to store the file
> elsewhere if desired.
>
> I guess you could accomplish that with the current API by writing a
> dummy-file to the composite storage and see where that file will get
> saved. But that seems pretty hacky and could result in security
> dialogs being displayed to the user.
> I think a better solution would be to simply add a .default property
> to DeviceStorage which is set to true for the default area, and false
> for all other ones.
The real issue I've been having is to get you, Doug Turner, and the UI folks to all agree on what's wanted and put forward a consistent set of requirements. That's all I've ever really wanted. I'm happy to implement whatever, I just can't have it changing every 3 days.
Dave Hylands
Jonas Sicking
May 20, 2013, 5:32:59 PM5/20/13
to Dave Hylands, dev-b2g
on exposing it to them since, in addition to the security issues, it
would mean that we'd have to standardize what settings we have and
what they can contain as part of the web platform.
>> What you can do, is to list all available store areas, and then in
>> addition to that have an option which says "default" without showing
>> the user any indication of where the file will be stored if "default"
>> is chosen.
>>
>> I would think that in a good UI you'd want to just list the available
>> storage areas, without a separate "default" option. And by default
>> select the area which the user has previously indicated should be the
>> default. That way the user can see where the file will be stored if
>> no
>> action is taken, and he/she can take action to store the file
>> elsewhere if desired.
>>
>> I guess you could accomplish that with the current API by writing a
>> dummy-file to the composite storage and see where that file will get
>> saved. But that seems pretty hacky and could result in security
>> dialogs being displayed to the user.
>
> Just query the setting and have the same named storage are pre-selected.
>
>> I think a better solution would be to simply add a .default property
>> to DeviceStorage which is set to true for the default area, and false
>> for all other ones.
>
> I'm perfectly happy to add such an attribute and it would be quite simple to do. We could even make it so that setting that attribute to true causes the appropriate setting/preference to change as well. I went ahead and filed bug 874213 to implement this.
not unless we have very good use cases as well as the security
infrastructure (dialogs etc) to support it.
> The real issue I've been having is to get you, Doug Turner, and the UI folks to all agree on what's wanted and put forward a consistent set of requirements. That's all I've ever really wanted. I'm happy to implement whatever, I just can't have it changing every 3 days.
here until we have a more comprehensive look at changes that we need
to do to DeviceStorage. The issues that I know about now are:
* How make the API support USB keys and sdcards on desktop platforms
where there's not an enumerable set of available slots.
* It's not good that every application has to scan all of device
storage on startup. It should be possible to only scan once.
* We should use a standardized filesystem API.
/ Jonas
Jed Davis
May 20, 2013, 6:23:39 PM5/20/13
to Andrew Sutherland, dev...@lists.mozilla.org
directory's size is fixed at filesystem creation time, and usually isn't
very large.
--Jed
Luís Matos
May 21, 2013, 5:40:27 AM5/21/13
to
Hello,
Is this API ready to be tested on Firefox OS devices / Simulator? If not will it be soon?
THanks in advance.
Is this API ready to be tested on Firefox OS devices / Simulator? If not will it be soon?
THanks in advance.
Dave Hylands
May 22, 2013, 8:48:12 PM5/22/13
to Luís Matos, dev...@lists.mozilla.org
Hi Luis,
The composite support for the DeviceStorage API has landed, and is being tested. There are a number of issues which are being addressed.
Or are you referring to the .getEditable function?
Dave Hylands
----- Original Message -----
> From: "Luís Matos" <luismat...@gmail.com>
> To: dev...@lists.mozilla.org
> Sent: Tuesday, May 21, 2013 2:40:27 AM
> Subject: Re: [b2g] Device Storage Changes
>
The composite support for the DeviceStorage API has landed, and is being tested. There are a number of issues which are being addressed.
Or are you referring to the .getEditable function?
Dave Hylands
----- Original Message -----
> From: "Luís Matos" <luismat...@gmail.com>
> To: dev...@lists.mozilla.org
> Sent: Tuesday, May 21, 2013 2:40:27 AM
> Subject: Re: [b2g] Device Storage Changes
>
Luís Matos
May 23, 2013, 6:33:17 AM5/23/13
to
Hello,
I was referring to DeviceStorage API itself since I hadn't had the chance to test it yet and didn’t know if it was already available (in an earlier version). I managed to test it some days ago and managed to save files to the gallery and the sdcard, which is what I need at this point.
In the future I might need the API to read files but at this point I’m still using a Pick WebActivity.
Thanks for your reply.
I was referring to DeviceStorage API itself since I hadn't had the chance to test it yet and didn’t know if it was already available (in an earlier version). I managed to test it some days ago and managed to save files to the gallery and the sdcard, which is what I need at this point.
In the future I might need the API to read files but at this point I’m still using a Pick WebActivity.
Thanks for your reply.
0 new messages