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

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

From: KOMATSU Kensaku <kensaku.komatsu@gmail.com>
Date: Fri, 22 Mar 2013 10:36:51 +0900
Message-ID: <CAKopxYyZ2dJunpdjZgVR=3fZkenMYt2-btc4PH8_8iQN5_q=kA@mail.gmail.com>
To: Greg Billock <gbillock@google.com>
Cc: 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>
I'm grad to see the progress about webintents issues ;-)

Was there any discussion about explicit intents? I guess explicit way
doesn't have
any UI issues and also fits well for unidirectional model.


2013/3/22 Greg Billock <gbillock@google.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 Friday, 22 March 2013 01:37:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:58 UTC