shindig-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Hjelmstad (JIRA)" <>
Subject [jira] Commented: (SHINDIG-1050) Implement active-relay-less transport for non-window.postMessage WebKit browsers
Date Thu, 07 May 2009 01:44:32 GMT


John Hjelmstad commented on SHINDIG-1050:

Patch at:

In it is implemented:
1. RMR transport for Safari < 4 and Chrome < 2.
2. Small improvements to rpctest harness (proper faked-gadget setup, grey background to suss
out visual artifacts from IFRAMEs).
3. window['console']['log'] --> gadgets.warn
4. "same-domain" transport simply does canonicalized protocol://host:port string matching
rather than relying on exception-based control flow.

> Implement active-relay-less transport for non-window.postMessage WebKit browsers
> --------------------------------------------------------------------------------
>                 Key: SHINDIG-1050
>                 URL:
>             Project: Shindig
>          Issue Type: Improvement
>          Components: Javascript 
>    Affects Versions: trunk
>            Reporter: John Hjelmstad
>             Fix For: trunk
> I and Joey Schorr have implemented a "final" gadgets.rpc transport for use by all remaining
significant browsers that still use IFPC (Safari < 4, Chrome 1).
> Dubbed RMR (Resizing Message Relay), this technique is identical to IFPC in terms of
security: container-to-gadget communication occurs through a sibling IFRAME to the gadget
on the gadget's protocol://host:port, with content passed in the fragment. G-to-C communication
takes place by a child IFRAME to the gadget on the same domain as the container.
> However, rather than relying on code in the relay actively running and relaying the content
to the receiver, the IFRAME's resize handler is used. Each receiver first obtains a reference
to its relay file in the sender's context (polling is used for this step), attaching an onresize
handler to it. This handler consumes the data on the IFRAME's fragment and processes it as
IFPC would. In order to indicate to the sender that message(s) have been received, special
ACK messages are sent by the receiver (optionally with additional messages for efficiency).
> This has two major benefits:
> 1. Much faster message passing. Latency per message is ~15ms vs. ~150-300ms for IFPC.
Message passing appears to be more reliable than with IFPC as well.
> 2. No need to host a special active relay file (rpc_relay.html). In the context of WebKit
(the only browser for which this method applies), *any* URL may be used as a relay. The implementation
uses the receiver's protocol://host:port/robots.txt for this purpose. Even if the file doesn't
exist, the resulting 404/500 is sufficient.
> Benefit #2 is of particular note. With this implementation, all major browsers are covered
by gadgets.rpc with a fast, active-relay-less transport. This makes life much easier for containers:
> 1. Containers need not host rpc_relay.html any longer.
> 2. The parent= param passed to each gadget render need only be the container's protocol://host:port
(window.location.href), and gadgets.rpc.setRelayUrl(...) is no longer strictly necessary,
since it is just the gadget IFRAME's protocol://host:port, which can be processed from the
> 3. IFPC code can be removed from rpc.js.
> For the moment, I won't be removing IFPC however, since A) I'd like to solicit others'
input on whether it's needed in any use case unknown to me; B) IFPC remains somewhat useful
for messages sent before the various transport mechanism's "handshakes" are complete. In a
followup, I plan to implement reliable early-message queueing to resolve this problem.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message