On Wed, Apr 30, 2014 at 6:14 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > As far as I know, there are two issues with XHR when it comes to local > file input: > 1) It wants a URL instead of an nsIFile and nsIFile doesn't have a > getter for a URL pointing to the same file, so there's a mismatch > between what you have and what XHR wants.
This isn't really a big issue - OS.File already uses paths rather than nsIFile, so we're already moving away from those, and calling Services.io.newFileURI(nsIFile) is easy. > 2) I think (but am not sure) that our file channels pump > OnStopRequest too soon compared to how network-backed channels work, > so that might be a source of bugs. We really should ensure that async > open on a file channel truly is async in the sense that event loop is > always guaranteed to spin between the opening and OnStopRequest. These kinds of issues are my primary concern. Also performance differences (I don't think XHR was optimized for local file I/O patterns, whereas OS.File was). But probably a bigger issue with expanding use of XHR for chrome code is that code rarely only wants to read files. OS.File offers much more extensive functionality (including writing, copying/moving, deleting, retrieving attributes, etc.), and if you're going to be using OS.File for those anyways, you might as well also use it for file reading. Gavin _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
