Re: Web Intents/Web Activities F2F get-together report

Greg

Thanks for the report, and thanks to you Darin, Jonas and Mounir for meeting.

I assume that this means we will (1) continue with some deeper discussions and proposals on this list and (2) that we can and should reserve time (e.g. a day or 1 1/2 days) in the DAP F2F agenda 4-6 June for this topic [1].

Are these both correct assumptions?

Perhaps it would make sense to pick a topic to share more details on the list to get some discussion started - I assume the uni-directional approach is a good place to start. It might help to summarize the flow, and the  implications of this change on the functionality and user experience. In addition, Mounir, is it possible for you to share more on the list about this topic from the Firefox OS point of view?

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group

[1] DAP F2F to be held in Düsseldorf, Germany 4-6 June 2013.

On Mar 21, 2013, at 4:43 PM, ext Greg Billock wrote:

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.