For parity with the Gecko API [1], the HTML implementation should support an launch() method exposed to content. It should do nothing unless the content is a dashboard; if it is, the current mgmt.launch() behavior should be used. [1] http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/apps/nsIDOMApplicationRegistry.idl

This removes the onsuccess and onerror callbacks to launch(). Is that what we want?

Jonas?

Catching errors like popup blocking is actually kind of hard in the HTML case, so losing these currently-unreliable callbacks would make things a bit easier. But permission errors could be raised as exceptions immediately (not asynchronously). It's not clear to me from the IDL if an exception is expected. It certainly seems preferable to ignoring the call (as mhanson proposes).

Ian, the more I think about this method (and uninstall() also), the more I think they should belong to the Application interface. This would let people do : var request = navigator.mozApps.enumerate(); request.onsuccess = function() { request.result[0].launch(); } launch() itself could return an object with onsuccess/onerror handlers.

Did enumerate() get a new XHR-style interaction instead of a callback? I don't have a particular objection to a method in this case, but I feel like the API redesign is taking place in a very organic way that I find troubling. If we're going to redesign the API I believe we should do it collaboratively all at once, not through a series of hard-to-discover bugs. (Or in the case of the IDL, I don't know who, when, or how that was designed, only that it appeared.)

Web APIs are inherently designed in an organic way. Thats why its so critical to start prototyping early. We should have started putting this into the platform a year ago, then we would have some feedback and stability now as we are starting to layer products on top of it. Even once we have reached a stable state inside Mozilla, there is a good chance others will find further improvements in the standardization process and we will have to iterate more. We should definitely post the API to dev-platform and propose it to W3C asap for exactly this reason.

My comment about organic design in this case refers to a bug about implementing changes to a particular method not being a good place to discuss the pros and cons of introducing an object with methods; such a discussion should take into account how that would change all the methods. Similarly we haven't had a place to discuss the other changes (e.g., enumerate being introduced in a bug that was general to the entirety of the mozApps implementation). I would certainly welcome a discussion on dev-platform.

Yeah, lets do that. I asked Jonas a couple days ago to make a post explaining the current API and solicit feedback from dev-platform but I think he is on vacation right now. I will find out when he is back.

ianb, if I understood the latest discussion correctly we will leave launch on mgmt? (I had to step out during the meeting, correct me if this changed in the meantime). If so, should we re-purpose this bug and use it to move launch in Gecko?

The specifics of this but are obsolete, as the interface has changed since this was created, and I believe there is another tracking bug for the HTML implementation of the interface as a whole.