Closed Bug 945540 Opened 6 years ago Closed Last year
.jsm file i/o to OS .File, Promises
Spin-off of bug 915838 comments 12 through 15. XPIProvider's installAddon code uses nsIFile, but we want to use asycnhronous OS.File code instead. needinfo: Should this bug block 915838? Yoric says yes; I say no. Need a module owner's call on that.
Adding more main-thread I/O is not acceptable. I assume that's what the patch in bug would do without this work?
(In reply to Alex Vincent [:WeirdAl] from comment #0) > needinfo: Should this bug block 915838? Yoric says yes; I say no. Need a > module owner's call on that. Not a blocker. See bug 915838 comment 16.
XPIProvider.jsm tries to implement a transactional model, whereby if an operation fails, we try to roll it all the way back. Obviously, that has to be included in the OS.File migration... but I wonder if it might be worth splitting that capability off into its own JSM. More specifically, any file operation should be undoable. It might be best to create nsITransaction objects for every kind of file move we need and use a native transaction manager to drive the process. I have quite a bit of experience with Mozilla's transaction manager and converting operations to transactions. The transaction manager works; we might as well use it for the undo/redo requirement. Combining JS-based transactions with OS.File could be a fun exercise. It'd be useful beyond XPIProvider, too: undoable file i/o has applications in editing.
Follow-up to comment 3: the native transaction manager is designed to run synchronously; if we did what I suggested, the txmgr would have to live on a separate worker thread.
Ignore comments 3 and 4: I just discovered XPCOM isn't available to chrome workers. So I couldn't get that txmgr if I wanted to.
Blair, I have implemented an async txmgr using Promise and Task, and with Jasmine-based tests, if you're interested: http://sourceforge.net/p/verbosio/templates/code/ci/default/tree/src/transactions
Is this still desirable? Thanks to a spammy comment, I was forced to revisit this briefly. XPIProvider seems to be deprecated code, with the advent of Web Extensions.
WebExtensions are still packaged as XPI files but we have a more recent bug with patches, duping to that.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → DUPLICATE
Duplicate of bug: 1462855
You need to log in before you can comment on or make changes to this bug.