dojox.io.proxy does xdomain communication and it was updated for Dojo 1.1, but there is a newer option in the nightly builds of Dojo: dojox.io.windowName. dojox.io.windowName may be easier to set up.

There are test files in the dojox.io directory, and Kris Zyp wrote up some articles for dojox.io.windowName here:

http://www.sitepen.com/blog/2008/07/22/windowname-transport/
and
http://www.sitepen.com/blog/2008/08/18/protected-cross-domain-access-wit...

Thank you, James.

I did try to use the dojox.io.proxy in dojo 1.1.1 download but when I set the test up (the test provided with the distribution) , I kept getting "Error: xhr cancelled." I did try to fix that issue but ran into some other issues before giving up. The windowName seems to be a way to talk to a web service (a server side entity) rather than sending a message across to Javascript on a iframe that points to a different domain, correct? In that case, I would still like to get the dojox.io.proxy method working for me since my requirement is to send a message to an iframe pointing to a domain different from that of the main page in which the iframe resides.

Hi
Can the window.name transport be used for the following scenario:
1. Main html page has an iframe pointing to another domain page. The iframe page contains a function called onMsgReceived()
2. I send a message to the iframe which triggers the method onMsgReceived()
3. Similarly, the onMsgReceived can eventually send a message to the main page intercepted by another similar Javascript function on the main page.

I believe the dojox io proxy can be used for this but I am unable to make the tests work on my machine. Can someone confirm if they can deploy the io proxy tests (in dojox/io/tests) on their local machine successfully to accomplish the above task?

Thanx!
Menon

Menon, it does seem like the dojox.io.windowName is not set up for the scenario you describe. dojox.io.proxy is not set up for the onMsgReceived scenario either, particularly if you want it to be a persistent iframe: dojox.io.proxy is meant to do one XHR call across frames, then it destroys the frames.

Here is a working example of dojox.io.proxy:
http://turtle.dojotoolkit.org/~jburke/xip102/proxy/xipxd.html

I did a quick persistent frame-to-frame communication test for a co-worker here:
http://www.tagneto.org/xdm/XdMessage.html

It does not use Dojo, and it has the frame endpoints hard-coded, but it might give you some ideas. Also, it does not handle large messages, just one message limited by the size of the GET call. You might be able to work out your own message segmenting on top of it. Also note it will not work in the Opera browser -- the code should really fall back on using the HTML5 postMessage feature, which should work for Opera. That should have a side benefit of working in Firefox 3 too.

Thank you for pointing to the persistent frame-to-frame communication test...I will take a look.

In fact, since I need to send larger messages than is currently allowed by IE in one shot, I am writing my own segmenting scheme for Julien's cross-domain utility.

Thanx for all the support!
Menon