- From: John J Barton <johnjbarton@johnjbarton.com>
- Date: Sat, 11 Feb 2012 17:13:10 -0800
- To: Paul Kinlan <paulkinlan@google.com>
- Cc: Charles Pritchard <chuck@jumis.com>, WebIntents <public-web-intents@w3.org>
On Sat, Feb 11, 2012 at 2:33 PM, Paul Kinlan <paulkinlan@google.com> wrote: > Hi Charles, Charles lured me over here, so I'm hijacking your reply ;-). > > 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 dynamic load (picked by user or algorithm or whatever) is easier in that the code dedicated to the problem can start the communications in the parent page. It won't matter when the iframe sends its first message because the parent will be ready. The embed case would like to work independent of the relative order of the processing.(Think dynamic script loading eg require.js). And the embed case would like to disassociate the communications code from the widget placement. Therefore this case is harder: we don't know if the parent is ready when the iframe postMessages. > > 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. I made pretty much the same argument over on the webapps newsgroup. Ian Hickson provided some guidance that makes the problem slightly better. Rather than use 'load' event processing, the handshake business is handled by postMessage -> global 'message' handler, then the communications operates over MessagePorts. The resulting protocol does not rely on 'load' or order; no in-band messages like 'ready' muck up the communications. On the other hand, devs must do the handshake thing and MessagePorts are not universally available. I'm working with Kris Kowal on q_comm, a library that supports iframes (same and cross-domain), sockets, and workers. Cross window should also be possible. On webapps group I claimed that a handshake standard bit was critical for interoperable cross-domain communications. I was surprised that this was not agreed. jjb
Received on Sunday, 12 February 2012 01:13:42 UTC