- From: Greg Billock <gbillock@google.com>
- Date: Thu, 21 Mar 2013 13:43:14 -0700
- To: WebIntents <public-web-intents@w3.org>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>, "Frederick.Hirsch@nokia.com" <frederick.hirsch@nokia.com>
- Message-ID: <CAAxVY9dKFg7Y5OBwZ0S+pPjJqbEqVwaByYNz+_v4S6wERVA0Rg@mail.gmail.com>
Chrome (Greg Billock and Darin Fisher) and Mozilla (Jonas Sicking and Mounir Lamouri) folks got together recently to talk about Web Intents/Web Activities, and exchange information and ideas. Here's a summary, and some food for thought about a direction forward: 1. We spent quite a bit of time discussing the issues with the Chrome Web Intents experimental implementation that we discussed in TPAC -- the difficulty of indicating cross-tab coordination and the state of that coordination, difficulties with bidirectional communication given two communicating contexts, etc. FirefoxOS is not dealing with a lot of these issues with Web Activities -- the handler contexts tend to be system-originated and replace existing UI. 2. We discussed ways to address these problems. The most promising soun like limiting handlers to inline-only and/or restricting communication to unidirectional-only. This handles many use cases and may provide a way to ease some of the UI constraints. A possible direction is to enable bi-directional communication through including a target URL in the unidirectional invocation, such that the target is able to invoke to, for example, save an edited document. 3. We discussed switching the governance of the disposition such that the client always controls the disposition context. That is, source pages would control whether the handler ran inline or in another tabbed/overlapped context. This seems like a promising change -- it reduces the unpredictability of the UI for clients. There's a question as to how much disposition negotiation could occur that would need to be resolved. This also allows a path to another embed-like disposition which acts more like a plug-in. 4. We spent time talking about the right context in which to handle invocations in a reduced scope -- should this be analogous to a shared worker? But those don't have access to any DOM. Should they be analogous to Chrome's event pages? Having a DOM is convenient, but is that convenience worth the cost? 5. There's a possible ramp-up opportunity where we start with inline/unidirectional data flow and see how far that takes us. Some of these ideas give us confidence we're not trapped, and we can perhaps ease our way past the most challenging UI problems. This direction is pretty much the scope of what Mozilla is doing with Firefox OS, so we hope to learn a lot from that.
Received on Thursday, 21 March 2013 20:43:42 UTC