1093480 - Implement an asynchronous transaction manager module

Status: RESOLVED WONTFIX

(Toolkit :: Async Tooling, defect)

Description

[Alex Vincent [:WeirdAl]]

I think I will break this patch up into several incremental patches:

* Inline API documentation, errors and basic infrastructure (stack of transactions, PromiseAction, isInTransaction)
* doTransaction
* undoTransaction
* redoTransaction
* Transaction listeners
* Merging transactions
* Transaction metadata
* Undo / redo stacks (getting, clearing)

Each phase will have its own tests as well.

Comment 1

[Alex Vincent [:WeirdAl]]

Attachment: part 1: Define the API.

Comment 2

[David Teller [:Yoric] - still alive but not very active]

Can you describe the expected use case for this ATM?

Comment 3

[David Teller [:Yoric] - still alive but not very active]

Comment on attachment 8519454 [details] [diff] [review]
part 1:  Define the API.

Review of attachment 8519454 [details] [diff] [review]:
-----------------------------------------------------------------

At first glance, the API looks sound, but I can't review it until I have a good idea of the usecase.

Comment 4

[Alex Vincent [:WeirdAl]]

The immediate use case is Firefox's addons manager:
http://hg.mozilla.org/mozilla-central/annotate/ae27ae77e32f/toolkit/mozapps/extensions/internal/XPIProvider.jsm#l297

You may recall that the AOM uses several sychronous nsIFile operations to update an addon, for instance.  AOM's actually implementing a simple transaction with its SafeInstallOperation code.  Bug 945540 is about converting to OS.File and Promises for asynchronous operations, so it could use the Transaction code I've implemented.

(That being said, AOM may not require the full AsyncTransactionManager, just a singleton Transaction.  I'm willing to redesign for that purpose only, if you require this.)

Mozilla's built-in transaction manager component (editor/txmgr) supports undo/redo operations in general, but is not designed for asynchronous operations.  I implemented AsyncTransactionManager for that purpose in my Verbosio project, so that I could have undo and redo capabilities for async, atomic changes.

Comment 6

[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 7

[Alex Vincent [:WeirdAl]]

Kris, please answer comment 6.

Comment 8

[Kris Maglione [:kmag]]

(In reply to Alex Vincent [:WeirdAl] from comment #6)
> 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.

It should no longer be necessary.