You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shindig.apache.org by "John Hjelmstad (JIRA)" <ji...@apache.org> on 2009/05/07 03:38:30 UTC
[jira] Created: (SHINDIG-1050) Implement active-relay-less
transport for non-window.postMessage WebKit browsers
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.
[jira] Resolved: (SHINDIG-1050) Implement active-relay-less
transport for non-window.postMessage WebKit browsers
Posted by "John Hjelmstad (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SHINDIG-1050) Implement active-relay-less
transport for non-window.postMessage WebKit browsers
Posted by "John Hjelmstad (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706692#action_12706692 ]
John Hjelmstad commented on SHINDIG-1050:
-----------------------------------------
Patch at: http://codereview.appspot.com/62051
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: 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.