Re: Exploring an Intents protocol for web messaging

On 2/12/2012 10:08 AM, John J Barton wrote:
>> >  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.
> I think the dance/ping is fundamental to communications, so I guess
> you mean "move the dance/ping into the browser code".


I used a similar shortcut for the dance/ping mechanism with web sockets. 
But I don't know if I'd recommend it for general use.
With websockets we have binary and text strings. So my binary is my 
payload and my text strings are my protocol.
And I get to skip some handshaking because of that. Using the transfer 
and message arguments sounds pretty similar to that.

Handshakes are for our benefit. If we want to cut down on the code 
needed to handshake, yes, I think adding startActivity to IFRAME might 
help, as it'd just be a shortcut.
It'd be a standard name we can use in polyfill code as well.

So here's a couple use cases I've come across:

Site A embeds an iframe to Site B; the content on Site B is an image. 
Site A is able to request the image data from Site B.
It's helpful to have a get mechanism, so that Site B only transfers the 
data when requested.

Site A embeds an iframe to Site B; the content on Site B is an image and 
audio. Site A sends a ping request to Site B, starting the audio;
and informing Site A that the audio is available, supported and can be 
requested in a byte array.

Then, we have the other side of things.

Site A embeds an iframe to Site B; Site A wants to share a link and 
description with Site B.
This can be handled via post requests, of course, for fallback. But it 
can also be handled via postMessage, which is what we're looking at.

Site A embeds an iframe to Site B, which supports both intent 
registration and postMessage Intents; Site A sends a handshake,
Site B sends a list of available actions.

Notice that none of this requires CORS. That's the cool part. All of it 
can be done over postMessage.

None of this is meant to take away or suggest web intents is 
unnecessary. It's just about exposure. This extends exposure.
I've worked with most of these use cases. They're really handy for 
<iframe sandbox=allow-scripts>.


-Charles

Received on Sunday, 12 February 2012 20:20:26 UTC