[
https://issues.apache.org/jira/browse/SHINDIG-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hjelmstad resolved SHINDIG-1050.
-------------------------------------
Resolution: Fixed
Committed this code. See
http://shindig-dev.markmail.org/search/?q=rpc.js#query:rpc.js+page:1+mid:uvfylmfbjc362nsm+state:results
for further plans for rpc.js.
> 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.
