Re: connection ceremony for iframe postMessage communications

On Thu, Feb 9, 2012 at 11:49 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> That doesn't help with the second problem, of course....

Ok here are some ideas, riffing off the web messaging doc

1 To iframe element add:
    readonly attribute MessagePort port;

'message' events from the iframe to the containing window (via
window.parent.postMessage) will be delivered to any port listener (as
well as the global window handler).
   This solves the multiplexing part, the container listens to a
per-iframe object.

'connect' event would be raised and delivered (synchronously) as soon
as the iframe issues window.parent.addEventListener('message'...) and
vice versa.
   This solves the async start up part, each side waits for 'connect'
before issuing its first postMessage. The 'connect' for the
second-place racer triggers the first real message.

Pro: also solves the
cross-domain-iframes-don't-really-have-contentWindow problems I
discussed before.
       familiar addEventListener API, reuses MessagePort
       existing iframe code would just work

2. Have HTMLIFrameElement implement MessagePort.
  This is similar to #1 but the message port functions are attached to
the iframe element directly rather than to its port property.

Pro: resembles Worker
Con: resembles Worker.


3. To window add:
  [TreatNonCallableAsNull] attribute Function? onconnect;
The function would be called when the iframe issues
window.parent.addEventListener('message')

The onconnect event delivers a 'port'; the event.target would be the
iframe element
    This solves the multiplexing problem: the container listens to a
per-iframe port object. Container can compare the event.target to its
iframes to decide which port is associated with which iframe.
    This solves the async startup by causing the container to act like
a server: it must listen for connections early.
(Modeled on http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#handler-sharedworkerglobalscope-onconnect,
since the parent window is shared by all of its enclosed iframes )

This second one seems like it "solves" the async problem by cheating.
Couldn't we just issue addEventListener('message',...) "first" in the
parent window? The reason 'connect' is better is that it is
out-of-band. If we use 'message' for setting up the connection, then
we must hold postMessage traffic until we get the first 'message'.
Thus the logic in the message handler must have two paths switching on
'first', exactly the problem we try to avoid. With 'connect', the
'message' handler just focuses on communications, not set up.

Pro: A bit more modern, as it follows SharedWorkers
       Seems like it could be expanded to inter-window communications
a la Web Intents
       Again it seems like the iframe code is all the same.

While I have experience with the iframe problems, I don't have
experience with the features I've cobble together here. Any feedback?
If I had any hints about the issues involved in a real implementation
and standard I'd work on simulating this with JS.

jjb

Received on Thursday, 9 February 2012 23:44:10 UTC