On Tue, Apr 29, 2014 at 6:27 PM, Gavin Sharp <ga...@gavinsharp.com> wrote: > Ah right, I had forgotten about those issues. That's in fact exactly the > code that Henri was looking at. XHR would perhaps be better than the XPCOM > IO if it works, but I don't think anyone's done that investigation.
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. 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. Anyway, since XHR is provides the operation "read file into a JS string" and "read file, parse it as JSON and return the object", it seems sad that jsms hand-roll those operations from XPCOM pieces over and over again. Currently, XHR JSON doesn't have much of a memory or event loop niceness benefit over reading a file into a JS string and passing the string to JSON.parse(), but if we saw a lot of performance-critical use of XHR JSON, it would be *possible* to introduce an incremental JSON parser and make XHR use it behind the scenes. Such an optimization benefiting all callers (internal and on the Web) will never happen if XHR JSON isn't used and everyone first buffers to a JS string and then passes it to JSON.parse(). Also, if XHR was responsiveness-critical for encoding conversions, it would make sense to take the time to make the encoding conversion happen off the main thread and let the Web benefit. Now, if all such responsiveness optimizations go into OS.file, they won't benefit Web apps. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
