715015 - add self.data.contents() API to enumerate files in data/

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[Brian Warner [:warner :bwarner]]

In bug 714994, I mentioned how it'd be nice to offer a better data/-enumerating API than .toFilename . The specific use-case is the OpenWebApps code (in https://github.com/mozilla/openwebapps/blob/0af54cbc1a35230f23a00f5067508ce258a55c21/addons/jetpack/lib/nativeshell.js#L348) which wants to recursively copy (and modify) a subtree of the addon's data/ directory into a new location on the user's filesystem. It needs to get a list of the files in that directory and read the contents of each one. That code currently uses .toFilename() to obtain a on-disk pathname of the unpacked XPI data/ directory, then uses require("file") to list the contents of that directory and read each file.

Here's the proposal:

* modify the XPI-generation process to record a list of files in each data/ directory. (this was always part of the manifest plan, but the current code doesn't quite retain the data-manifest portion.. part of the code in bug 685378 fixes that)
* add require("self").data.contents(prefix=""), which returns a list of /-joined pathnames
 * each returned pathname represents a file in the package's data/ directory, and can be passed to require("self").data.url(PATHNAME) or .load(PATHNAME)
 * the optional prefix argument causes the list of pathnames to be filtered down to just the ones that start with that prefix, and the prefix will be stripped from each pathname. So contents("subdir/") would return all the files below subdir/, without the "subdir/" prefix. The default returns the whole list.
 * this API would list files only, not directories. I'd like to keep the self.data model simple by having it only expose files, rather than both files and directories. Calling code doing a recursive copy may need to mkdir() missing parent directories before writing out each file. Empty directories, if really necessary, may need special handling.
 * the pathnames returned are /-joined, even if local filenames on the current platform use backslashes. The XPIs generated by the SDK use forward-slashes internally, so this API will stick with that format. Callers who want to compute local OS filenames for each data/ member (e.g. recursive copy of data/ into the local filesystem) will need to split on "/" and then join on the local platform's separator.

Comment 1

[Erik Vold [:erikvold] (please needinfo? me)]

Can we wontfix this one?

Comment 2

[Jeff Griffiths (:canuckistani) (:⚡︎)]

We're not going to take this.