Implement active-relay-less transport for non-window.postMessage WebKit browsers
--------------------------------------------------------------------------------
Key: SHINDIG-1050
URL: https://issues.apache.org/jira/browse/SHINDIG-1050
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 IFRAME.src.
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.
