Re: Async Transaction Manager: needs home, reviewers
On 01 Nov 2014, at 20:50, Kyle Huey m...@kylehuey.com wrote: On Sat, Nov 1, 2014 at 12:42 PM, ajvinc...@gmail.com wrote: The reviewer should understand asynchronous Promise operations, preferably the OS.File promises We shouldn't be landing new code that uses Promise.jsm in mozilla-central. Well, that surely hasn’t been communicated properly yet, so I doubt everyone knows about this move. Don’t get me wrong, I’m all for it, but I *think* we don’t want to smother our newfound love for Promises - which Promise/ Task.jsm certainly fuelled - with a transition that lacks a clear upgrade path. My question, for example, is: does our Structured Clone algo implementation support the DOM Promise object(s)? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
On Mon, Nov 3, 2014 at 10:55 AM, Mike de Boer mdeb...@mozilla.com wrote: On 01 Nov 2014, at 20:50, Kyle Huey m...@kylehuey.com wrote: On Sat, Nov 1, 2014 at 12:42 PM, ajvinc...@gmail.com wrote: The reviewer should understand asynchronous Promise operations, preferably the OS.File promises We shouldn't be landing new code that uses Promise.jsm in mozilla-central. Well, that surely hasn’t been communicated properly yet, so I doubt everyone knows about this move. Well, there was https://mail.mozilla.org/pipermail/firefox-dev/2013-November/001137.html Don’t get me wrong, I’m all for it, but I *think* we don’t want to smother our newfound love for Promises - which Promise/ Task.jsm certainly fuelled - with a transition that lacks a clear upgrade path. If you know of anything that doesn't work, please file a bug blocking bug 939636. If you really want to use defer() (which you shouldn't, because it makes your code less weby), you can do something like: http://mxr.mozilla.org/mozilla-central/source/dom/bluetooth/tests/marionette/head.js#47 My question, for example, is: does our Structured Clone algo implementation support the DOM Promise object(s)? No, and the spec doesn't either. What on earth would the semantics of promise cloning be? Are people doing that with Promise.jsm? bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
On Sunday, November 2, 2014 11:45:52 AM UTC-8, David Rajchenbach-Teller wrote: This looks like toolkit/ stuff. If you can segment this in small patches, I can try and review it. Cheers, David How small are we talking? Other than making the tests a separate patch, I'm not sure splitting the module up into smaller patches would be very helpful. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
https://bugzilla.mozilla.org/show_bug.cgi?id=1093480 Comment 0: 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. On Sunday, November 2, 2014 11:45:52 AM UTC-8, David Rajchenbach-Teller wrote: This looks like toolkit/ stuff. If you can segment this in small patches, I can try and review it. Cheers, David On 01/11/14 20:42, ajvinc...@gmail.com wrote: In a couple weeks I'll be doing some work on Firefox-as-a-platform-SDK (replacement for XULRunner) and addon infrastructure work. Part of that latter bit would be support for asynchronous file operations in the AddonManager. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
This looks like toolkit/ stuff. If you can segment this in small patches, I can try and review it. Cheers, David On 01/11/14 20:42, ajvinc...@gmail.com wrote: In a couple weeks I'll be doing some work on Firefox-as-a-platform-SDK (replacement for XULRunner) and addon infrastructure work. Part of that latter bit would be support for asynchronous file operations in the AddonManager. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
Current source code: http://sourceforge.net/p/verbosio/templates/code/ci/default/tree/src/transactions/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Async Transaction Manager: needs home, reviewers
In a couple weeks I'll be doing some work on Firefox-as-a-platform-SDK (replacement for XULRunner) and addon infrastructure work. Part of that latter bit would be support for asynchronous file operations in the AddonManager. The file operations, however, have to be revertable in the face of an error. To support that (and for other needs), I've written an asynchronous transaction manager (ATM) module, modeled after Mozilla's own transaction manager code. It should be more than adequate for AddonManager: one transaction comprises multiple asynchronous actions in a microtask. I am looking for someone who's willing to review this code and to help me refine it for mozilla-central. The reviewer should understand asynchronous Promise operations, preferably the OS.File promises, and should be willing to learn about the existing editor/txmgr code we currently have. (Like the rest of the editor code, I believe txmgr is basically unowned right now. But it is actually a pretty good component!) I'm also looking for a place to put an AsyncTransactionManager in the source code, probably in toolkit/modules, I'm thinking. Here's how it currently works: * The module exports a PromiseAction constructor with do, undo, redo methods. Each method should be replaced by the caller with a method that returns a Promise object. A do() method represents executing the action for the first time. The undo() and redo() methods represent reversing and restoring the single asynchronous operation of do(), respectively. * A transaction is basically a sequence of PromiseAction objects. * The ATM provides a doTransaction() method. The arguments currently are: *# intent: A string describing the transaction as a whole. *# code: An arbitrary value, recommended as a flag for merging the transaction into the previous transaction. *# merge: A method of the new transaction object: to determine if a following transaction should be merged into the transaction. *# task: A generator function yielding several PromiseAction objects in sequence. The transaction object is built from these. Thus, the user doesn't need to pass in Transaction objects. * If a PromiseAction's do() method yields a Promise which is eventually rejected, this is treated as an abort, and the ATM attempts to roll back the transaction by calling each successful PromiseAction's undo() method, in reverse order. * Likewise, an aborted ATM.undoTransaction() call results in successfully undone PromiseAction instances having their redo() methods called in forward order. Similarly, an aborted redo() call results in undo() calls on PromiseAction objects, in reverse order. * The ATM provides undoTransaction() and redoTransaction() methods, that take no arguments. These undo and redo individual transactions. * While asynchronous operations on a transaction are underway, calls to the ATM's doTransaction(), undoTransaction() or redoTransaction() methods automatically throw an exception. * There is also support for listening to transaction manager events ([willExecute, didExecute, willAttemptMerge, didAttemptMerge], [do, undo, redo]). I have a test suite already written and passing in Jasmine code; I'm perfectly willing and capable to port the tests to xpcshell-tests. Alex Vincent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
On Sat, Nov 1, 2014 at 12:42 PM, ajvinc...@gmail.com wrote: The reviewer should understand asynchronous Promise operations, preferably the OS.File promises We shouldn't be landing new code that uses Promise.jsm in mozilla-central. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
On Saturday, November 1, 2014 12:50:24 PM UTC-7, Kyle Huey wrote: On Sat, Nov 1, 2014 at 12:42 PM, ajvinc...@gmail.com wrote: The reviewer should understand asynchronous Promise operations, preferably the OS.File promises We shouldn't be landing new code that uses Promise.jsm in mozilla-central. - Kyle I understand and agree... right now my module uses Promise.jsm, but I'd think it trivial to convert that to native Promise objects. Task.jsm, though, still uses it, and the module I'm proposing relies on Task.jsm pretty heavily... Are there plans to break Task.jsm's dependency on Promise.jsm? If not, is that okay? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
The differences are as follows: - DOM Promise don't implement Promise.defer; - the scheduling of asynchronous tasks will sometimes be different. If you rely on neither, you should be ok. Task.jsm will be migrated to DOM Promise once we are satisfied that it doesn't break anything on m-c. Cheers, David On 01/11/14 21:00, ajvinc...@gmail.com wrote: On Saturday, November 1, 2014 12:50:24 PM UTC-7, Kyle Huey wrote: On Sat, Nov 1, 2014 at 12:42 PM, ajvinc...@gmail.com wrote: The reviewer should understand asynchronous Promise operations, preferably the OS.File promises We shouldn't be landing new code that uses Promise.jsm in mozilla-central. - Kyle I understand and agree... right now my module uses Promise.jsm, but I'd think it trivial to convert that to native Promise objects. Task.jsm, though, still uses it, and the module I'm proposing relies on Task.jsm pretty heavily... Are there plans to break Task.jsm's dependency on Promise.jsm? If not, is that okay? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
