Hi George,
I've implemented a transport based on window.name for gwt-rpc-plus based on the
research done by the Lombardi folk and Ray Cromwell (and some incremental
improvements), so I can give you a few pointers:
* window.name has no appreciable limit in any of the shipping browsers. I've
pushed it to at least 1MB on each without any trouble.
* Instead of polling for window.name, redirect your result back to a page on
the other domain (favicon.ico works in most cases). This will fire an onload
event (or onreadystatechange in IE) that you can use to check for a successful
window.name load.
* For IE browsers, create the form and iframe inside an
ActiveXObject('htmlfile') to avoid the navigation clicks for every submission
* Use postMessage to send back results on browsers that support it to cut the
request latency by 50%. HTML5 specifies that window.name won't be preserved
across cross-domain browser navigations, so it's possible the window.name
technique may stop working at some point in the future.
* I haven't found any way to catch lower-level errors (ie: host
resolution/connection errors) aside from using a timeout
* Remove the iframe after a small delay to avoid the infinite loading spinner
in Firefox (a la FormPanel)
I've documented the process I use in more detail here:
http://grack.com/blog/2010/01/04/more-on-window-name-cross-domain-transports/
For reference, the transports that we use in production
(WindowNameTransportRequest and PostMessageFrameTransportRequest) live in this
folder:
http://code.google.com/p/gwt-rpc-plus/source/browse/#svn/trunk/gwt-rpc-plus/gwt/com/dotspots/rpcplus/client/transport/impl
Matt.
On 2010-01-13, at 3:29 AM, George Georgovassilis wrote:
> Hello All,
>
> Recently I encountered the need to perform some cross domain RPC
> without using the server for relaying it. I had some good reads on
> that [1]. This weekend I think I came up with an approach that does
> without noticeable performance impacts. It use the window.name
> tranport [2] technique.
>
> The scenario:
>
> 1. Setup a custom RPCRequestBuilder which intercepts RPC calls
> 2. Setup a form and an iframe that points to the target domain
> 3. When the RPCRequestBuilder is fired, get the RPC payload (setData
> ()), feed the form and submit the form
> 4. Implementation detail: I could not get the form submission to
> contain the encoding headers required by the server side RPC
> implementation, so I'm faking them with a stub servlet filter infront
> of the RPC servlet.
> 5. Have the servlet process the request and return the RPC payload
> 6. The servlet now gets the payload and changes it into the following
> HTML:
> <body>
> <script>window.name='your rpc payload here'</script>
> </body>
> 7. On the browser side, the target frame setup in 2 is polled until
> window.name changes. The payload is then extracted and returned from
> the RPC request builder
>
> There are some problems here which should be solvable though:
> - It's said that window.name has some length limitations. So there
> would be a need for some sophisticated inter-frame communication that
> forwards chunks.
> - Error handling might get more complicated
> - I've not been able to set the request headers expected by the server
> side RPC implementation, hence I'm setting them on the server side via
> a pre-pended filter
> - I've not been able to setup the form and frame required by step 2
> via DOM manipulations; though I'd probably need to investigate that
> further, I could so far get it to work only when both the form and
> iframe were already existing in the HTML.
> - Tested on FF 3.5 only.
>
> Currently I'm trying to wrap this up and make it more user friendly
> and get it into some future release of the SL.
>
>
> [1]
> http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/94c18c4ec158070c
> [2] http://www.sitepen.com/blog/2008/07/22/windowname-transport/
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
