On Fri, 10 Feb 2012, John J Barton wrote:
> >
> > What I meant was just to do this on the receiving side (inside the 
> > iframe), after the onmessage handler has been set up (which we are 
> > assuming happens after the 'load' event for some reason):
> >
> >   parent.postMessage('load', '*');
> >
> > That way you don't have to depend on the 'load' event, you can just 
> > wait for the message from the inner frame. Then when you get it, you 
> > know you can start sending..
> 
> The problem here is that the iframe may issue parent.postMessage('load', 
> '*") before the parent onmessage handler has been set up.

You can always guarantee that you've set up your handler before you create 
the iframe. But, suppose that's somehow not possible. Then you just define 
"ping" as a message you can send to the inner frame, which the inner frame 
then responds to with the aforementioned "load" message.

So now you have the following situations:

 - parent is set up first, then opens iframe:
    - iframe sends 'load' message when ready

 - parent opens iframe, then sets up communications, iframe is quicker:
    - iframe sends 'load' message when ready, but it gets missed
    - parent sends 'ping' message
    - iframe sends 'load' message in response

 - parent opens iframe, then sets up communications, parent is quicker:
    - parent sends 'ping' message, but it gets missed
    - iframe sends 'load' message when ready

In all three cases, the first 'load' message that is received indicates 
that the communication system is ready.

(In practice it's usually much simpler than any of this because the parent 
can guarantee that it sets up its communications first, before the iframe 
is even created, and the child can guarantee that it sets up its 
communications before it finishes loading, so the parent can just use the 
regular 'load' event on the iframe and the child never needs to wait at 
all if it wants to start communicating first.)


> > And when you do send, you just send a message whose contents are just 
> > a single key saying what API endpoint you want, and a port, which you 
> > then use for all communication for that particular API call.
> 
> Just to clarify, I want to see the layer you just outlined be standard 
> so we can design iframe components and apps to mix and match. This can 
> be two simple layers on the current messaging: 1) the connection 
> ceremony, 2) the key/API format.

No reason for it to be standard, just define it as part of the protocol 
you are implementing over postMessage().

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply via email to