1130264 - Implement nsIVolumeService ("@mozilla.org/telephony/volume-service;1") for non-gonk platforms

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

While working on bug 825318 involving the downloads API, I observed that the downloads API depends on the existence of the Volume Service/nsIVolumeService to perform its mapping between the native file-system and the Device Storage namespace.  Device Storage does not provide a comparable interface that can be used instead.  This impedes creating hip new mochitests that run under mulet.

On bug 825318 comment 95 :jsicking requested the filing of this bug as a followup.  I'm filing this in Firefox OS :: General because that's where other similar bugs live, but it might be appropriate to move this to Core somewhere since the idea is to stop this being so B2G/Gonk-specific.

Comment 1

[Dave Hylands [:dhylands]]

There is a function VolumeManager::InitConfig https://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/VolumeManager.cpp#159 which reads /system/etc/volume.cfg to create/configure volumes which either don't exist in vold (the internal storage are on a nexus 4/5), or for which vold doesn't have appropriate attributes (removable, hot swappable).

By allowing the name of volume.cfg to configurable (perhaps through a preference?) then the portion of the VolumeManager which talks to vold could be #ifdef'd (or perhaps subclassed?)

Currently, all of the volume code is in dom/system/gonk, but it could be moved to dom/system.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Going maybe too high level for a sec, the motivating use-case for the downloads API is being able to map the native file-system paths into DeviceStorage paths, which is all webpages and webapps can speak.

Maybe this is the wrong spin-off and the right thing to do is to create a chrome-targeted XPCOM service nsIDOMDeviceStorageService that exposes a mapping API?

My specific rationale for this would be that it seems like on gonk platforms, nsIVolumeService is in charge of the mapping, and on non-gonk platforms, the directory service is in charge.  And where nsIVolumeService is just doing whatever /system/etc/volume.cfg or vold say (https://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/VolumeManager.cpp#159).  And it seems more awkward to have device storage pushing configuration into the volume service, whereas device storage nicely centralizes it all.

Longer term, the directory service could be largely mooted by nsIDOMDeviceStorageService and some chrome-specific helpers.  "pictures" is certainly a lot more useful than having to hard-code NS_OSX_PICTURE_DOCUMENTS_DIR/NS_UNIX_XDG_PICTURES_DIR/NS_WIN_PICTURES_DIR everywhere.

Comment 3

[Dave Hylands [:dhylands]]

That may make more sense (to introduce a mapping API).

Then the gonk volume stuff could register to be a mapper.

The significant difference between just using directories and using volumes, is that volumes can come and go.

From the device storage standpoint, a volume can be available (mounted and available for use), shared (the volume is being shared with a host via USB Mass Storage and it unavailable), and unavailable (media removed, or otherwise not mountable).

There is an effort underway to add runtime pluggable device storage areas, so that we can use network shares, or online services like dropbox. The mapper should probably tie in with that.

Comment 4

[BMO Automation]

Firefox OS is not being worked on