Cross-domain GET/POST extend from dojox/rpc/Service

[carrie.zhxj@…]

I have written two new dojox.rpc.transportRegistry components, XDGet and XDPost, for cross-domain rpc, using dojo.io.iframe and dojo.io.script .
Could you please review it, and point out the fault or defect for me.
Thanks, Carrie

The attached files includes:
1, dojoroot/dojox/rpc/XDomain.js
2, dojoroot/dojox/rpc/demos/xdomain.html (demo)
3, dojoroot/dojox/rpc/demos/templates/xdomain.html (demo template)
4, dojoroot/dojox/rpc/SMDLibrary/xdomain.smd (demo smd)

[rcoup]

Alex, apparently you chatted to carriezh on IRC about this? I've pointed out the style-guide requirements already.

[guest]

demo html

[guest]

demo template

[kriszyp]

We already have a cross-domain GET capability with the existing JSONP transport. As far as cross-domain POST, the SMD spec has tentatively included the IFRAME transport (which it appears is what you are implementing). However, as far as I can tell, the inclusion of the IFRAME transport is still an open issue with the SMD spec. There needs to be a solid definition of what IFRAME means in terms of communication on the wire, so that it can be defined in the SMD spec (I don't know what that definition is). Using iframes as the mechanism is a pointless definition, SMD definitions are not intended to define mechanisms, they are intended for servers to define how to access services. The SMD does not care about how you accomplish this communication.

[dmachi]

As Kris mentioned, thre is already cross-domain request with the existing JSONP transport. I don't mind adding a version of the XDPost transport. However the code here appears to implement a subclass of dojox.rpc.Service. This is something i'm trying to avoid. We want to impelment plugins that work so an smd can be written and based on the smd the appropriate transports and envelopes will be used. A good example of creating these plugins would be dojox.rpc.JsonRPC.

[dmachi]

Test Comment for batch edit