W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2013

Web Intents/Web Activities F2F get-together report

From: Greg Billock <gbillock@google.com>
Date: Thu, 21 Mar 2013 13:43:14 -0700
Message-ID: <CAAxVY9dKFg7Y5OBwZ0S+pPjJqbEqVwaByYNz+_v4S6wERVA0Rg@mail.gmail.com>
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>
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 GMT

This archive was generated by hypermail 2.3.1 : Thursday, 21 March 2013 20:43:43 GMT