Re: Exploring an Intents protocol for web messaging

Hi Charles,

Are you thinking that the iframes will be dynamically embedded or picked?
 Or the developer has explicitly chosen to embed say, the twitter widget?
 My answer mostly assumes that it is the latter.

The current postMessage mechanism inter-iframe communication is broken [1]
and I would love to see it get fixed, but the broken-ness may fit into your
model if the embedded site sends back to the client the protocol it will
only use for communication.

Alternatively, you might do iframe.postMessage(new Intent(.......)) and
said iframe will have to send back an intent object.

Not wanting to hijack the thread, but I was toying with the idea of
`[iframe|windowProxy].startActivity()` the other day. It would still have
all the same semantics and benefits of webintents now.  If I the developer
know the service I want to use, why should I go through intents picker to
take advantage of the API? With this we still get the request/response
semantics and the ability to use MessageChannel (which is a lot lot nicer
than plain post-message) and remove the dance/ping.  I suspect at first
people will huff and puff at the idea, but I like it and I wanted to throw
it out there.

A solution would be very useful for inline-widgets that support a
consistent interface AND the developer knows the service it wants to embed
(and probably trusts as well).

In the case of "share", the developer might embed the the twitter widget
and later switch it out for fb, but because they support the same action
the world is happier.

The issues/questions/thoughts that I have are:

   - For most solutions there is a larger dance that is needed and I hate
   dances
      - iframe/parent will have to agree they are sending the correct data
      - the developer has to do a lot of work - post message is still not
      as widely used in the wild (it is only really used by widget vendors such
      FB and Plus etc because they know they are communication back to
their own
      service and they know the entire service side API).
      - We need to know when we can send the data
      - What happens if we send more than one message down the channel
   - There is no need for client to send service a ping, instead service
   should send client a ping when it is ready with its capabilities.
      - But the assumption is that none of this is needed if the developer
      knows the iframe they are embedding.
   - I am warming to the idea of startActivity on [iframe/windowProxy]

[1] http://paul.kinlan.me/webmessaging-is-broken

On Sat, Feb 11, 2012 at 8:52 PM, Charles Pritchard <chuck@jumis.com> wrote:

> In a thread on Web Apps, titled, "connection ceremony for iframe
> postMessage communications", John Barton brought up some ideas about
> formalizing an iframe web messaging protocol.
>
> The web intents prototype/shim, over at http://webintents.org/ does
> something very similar.
>
> I'd like to explore a protocol for handling web intents over postMessage
> semantics. It may be very similar, or even match the semantics of the shim,
> or it may be a little different.
>
> John and I seem to have come to the same conclusion that a "ping" message
> is needed, to setup the handshake. In the case of postMessage, registration
> may not be an issue/on the table.
> It's more likely the case that site A wants to interface to site B, and
> site B has a general mechanism for any site to do so.
>
>
> -Charles
>
>


-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan