Hi Jonas,
...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).
> 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
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
