We currently have a hodge-podge of different File (and networking) APIs floating around (e.g., IOService, NetUtil.jsm, FileUtils.jsm, etc) to deal with reading and writing to files. Most of our file system access should be done asynchronously though, and currently, the preferred method is with NetUtil.jsm. I think we can do better, providing a higher-level API to handle basic stat functions and synchronous and asynchronous read and write methods to deal with the filesystem in the preferred manner without requiring the user to deal with channels and streams and obscure XPCOM services if they don't want to. for an example see node's fs.js: http://nodejs.org/docs/v0.5.6/api/fs.html

You could resurrect the api from bug 380813, (which has since been backed out)

See also the work that Irakli is doing for jetpack: https://github.com/Gozala/jetpack-io

The performance group is working on a low-level file API (see bug 563742). Jetpack is working on a high-level one. If anyone starts working on this, please synchronize with both!

is the Jetpack API going to be part of Jetpack or are they building it into browser/gecko? Guessing the former which is not going to satisfy this bug.

(In reply to Rob Campbell [:rc] (robcee) from comment #4) > is the Jetpack API going to be part of Jetpack or are they building it into > browser/gecko? Guessing the former which is not going to satisfy this bug. Probably Jetpack-only. Does anyone mind if I dup this to bug 563742?

(In reply to David Rajchenbach Teller [:Yoric] from comment #5) > Does anyone mind if I dup this to bug 563742? That one doesn't seem to have any async methods.

(In reply to Heather Arthur [:harth] from comment #6) > (In reply to David Rajchenbach Teller [:Yoric] from comment #5) > > Does anyone mind if I dup this to bug 563742? > > That one doesn't seem to have any async methods. Actually, it does have them.