945540 - Migrate XPIProvider.jsm file i/o to OS.File, Promises

Status: RESOLVED DUPLICATE of bug 1462855

(Toolkit :: Add-ons Manager, defect)

Description

[Alex Vincent [:WeirdAl]]

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.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Adding more main-thread I/O is not acceptable. I assume that's what the patch in bug would do without this work?

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(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.

Comment 3

[Alex Vincent [:WeirdAl]]

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.

Comment 4

[Alex Vincent [:WeirdAl]]

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.

Comment 5

[Alex Vincent [:WeirdAl]]

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.

Comment 6

[Alex Vincent [:WeirdAl]]

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

Comment 7

[Alex Vincent [:WeirdAl]]

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.

Comment 8

[Andrew Swan [:aswan]]

WebExtensions are still packaged as XPI files but we have a more recent bug with patches, duping to that.