Bombastic you say? Heresy? Nonsense. XMLHTTPRequest has been a nice try for browsers but really just doesn't make it all the way yet. Here I'll post my issues, followed by a different technique you can put to use today.
The reason for this thread is that I have an application I’m wrapping up that requires cross domain RPC. At first, looking at the discussions about it, I thought that XHR would fit the bill if done correctly. That is not true. I believed the propoganda that XHR is the best way to do remote scripting – that is also not necessarily true. So I researched my brains out to find how others are doing it and worked through a class to do my own RPC.
XHR Negatives: 
* XHR is implemented differently in different browsers. XHR is implemented differently in different versions of IE. Each version has it’s own idiosyncrasies and issues. XHR cannot be used in older browsers.
* XHR is security locked via the Same as Origin policy ie., you can only make requests to the domain where the PAGE came from. I would not have this argument if you could make requests to where the script came from, but that’s not what’s happening. There are a lot of valid and in fact forward looking reasons to allow cross domain RPCs – the most immediate thought that comes to mind is a mashup. XHR cannot do mashups without some serious assistance.
* XHR has problems. Natch, the 12030 problem and that entire thread. IE and XHR and SSH do not get along at all. XHR is not completely reliable as a communication mechanism, which makes programming around it more troublesome.
* XHR requires a significant amount of code. Some would argue that it does not take much to get an XHR request off. That is true. But to make it robust and stable for all possible browsers does take a lot of code – and quite a bit of experience with it to make sure you know what’s going right or wrong. An alternative is to use someone else’s library - but do you want to put a mission-critical system up where you don’t know how it all works and can walk through debugging it?
XHR Positives: 
* XHR does provide a strong remote scripting capability. It allows you to send packets of essentially any shape up to the server of origin, and receive packets of just about any shape for client-side interpretation. XHR is not the only way of doing this, but it does provide a reasonable framework for doing so.
* XHR can POST where most other mechanisms can only GET. This is important if you have really big amounts of data you want to get up to the server. If you have tiny (less than 2K) in total data per request that you need to get to the server, GET will do fine. IF you need more, POST, or else a packetizing mechanism with GET, is required.
* XHR is bound to the Same as Origin policy for security. Yes, I posted this in the negatives above as well. This can be seen as a huge benefit to the security minded, whereas the technique I’ll demonstrate below could potentially be compromised or misused in a way that makes it extraordinarily dangerous. XHR is very safe.
* XHR will allow more connections to the server by default than other mechanisms, which may rely on the threads that a browser will give you.
* XHR is unconcerned with the mechanism used at the server, or the return packet. No cooperation or cooperative code is required between the client and server.
My class:
XRPC or Crossdomain RPC.
Benefits of XRPC: * It is absolutely unbound to any domain or security policy. It violates every security policy of every browser out there effortlessly.
* It is very fast. It uses javascript in the most native way possible, as well as transmission being bound to the <script> tag, so it is high priority.
* The techniques that make this possible have been around since the beginning of JavaScript time ie., if a browser can run any version of JavaScript, it can execute this form of RPC. It is even more broadly accepted than iFrames.
* It’s small and tight. There are very few moving parts. There’s no multiple stages of connection, response codes and such – the transmission comes back or it doesn’t. Period.
* It is unlikely that the techniques used here will get modified in any significant way by the JS Language or the WWW council at any time in the foreseeable future.
Potential downsides of XRPC: 
* It is absolutely unbound to any domain or security policy. It violates every security policy of every browser out there effortlessly. Some might see this as a possible problem
* Debugging is, at first, a little more interesting. Messages about problems come back at you differently and it’s weird.
* Concurrency is weird. The browser will confine you to as many threads as it sees fit to go get your packets. This doesn’t stop your code, nor does it break it, but it can slow down responses a bit. If you need a hugely concurrent application this might not be the right fit for you.
* It takes more client-server cooperation to work than XHR – it is potentially less autonomous than XHR.
After researching a boatload of different techniques as broad as ActionScript, using images and cookies, extending XHR, various proxy solutions and Java, I settled on what is know as the Script Tag Hack.
This is a technique that you certainly know already, you’ve just not thought about it this way. You can call for a javascript file from any location. Think about it – you do not need to call for javascript from your home domain. And JS file names do not need to be .js – they can be .asp or .php or .pl and they can also have parameters. Additionally, using DOM techniques, we can “write” to the page a new script tag dynamically – meaning that we can spontaneously call for a new script that was never on the page in the first place.
So I created a little class that creates parameters and appends a new script tag to the bottom of the body tag on a document (it is invisible, just like any other script tag). The next steps are to send back a response that is interpretable, and lastly garbage collection. Interpretability is done by a small script at the server which creates valid JS and calls a handler that you define with the results. It is wrapped in a try/catch block, so if there are any troubles with the inbound script or processing in your handler, you’ll know it straight away. Garbage collection is handled by me placing another small instruction in the return packet that, after the call has been completed, looks for the script tag that was added to the DOM and removes it.
Without further ado, here’s the code for the client side portion of the XRPC:
__XRPC_UsageCounter = 0;
function XRPC(opURL)
{
if (!opURL) { var opURL = ''; }
this.url = opURL;
this.lastRequest = '';
this.__isIE = ((document.all) && (document.getElementById));
this.clearParams();
}
XRPC.prototype.clearParams = function() { this.__parmArray = new Array(); }
XRPC.prototype.param = function(pName, pValue) { this.__parmArray[pName] = pValue; }
XRPC.prototype.exec = function(handler)
{
if (!handler) { return alert('You must call XRPC.execute with a receiving function name as the handler'); }
var temp = new Array();
var ptr = 0;
for(parm in this.__parmArray)
temp[ptr++] = parm + '=' + escape(this.__parmArray[parm]);
var tempDate = new Date();
var uid = tempDate.getTime() + '_' + __XRPC_UsageCounter++;
this.lastRequest = this.url + '?uid=' + uid + '&h=' + handler + '&' + temp.join('&');
var newNode = document.createElement('script');
if (this.__isIE)
{
newNode.id = uid;
newNode.src = this.lastRequest;
} else {
newNode.setAttribute('id', uid);
newNode.setAttribute('src', this.lastRequest);
}
var target = document.getElementsByTagName('body');
target[0].appendChild(newNode);
}
Usage is fairly straight forward:
req = new XRPC(‘http://www.someOtherDomain.com/aFile.php);
req.param(‘theName’, ‘theValue’);
req.param(‘anotherName’, ‘anotherValue’);
req.exec(‘myHandler’);
At this point, this would have been thrown out as a <script src=> sort of request:
http://www.someOtherDomain.com/aFile.php?uid=1182389169957_0&h=myHandler&theName=theValue&anotherName=anotherValueNow at the server, I need to create some data and return a response:
<?php
XRPCResponse($_GET);
function XRPCResponse($theData)
{
$standAlone = ($recvFunc = $_GET['h']) ? false : true;
$garbage = ($uid = $_GET['uid']) ? "setTimeout('try { temp=document.getElementById(\"$uid\"); tempParent=temp.parentNode; tempParent.removeChild(temp); } catch(e) { };', 1000); " : '';
if ($standAlone)
{
echo "$theData\n$garbage";
} else {
$theData = json_encode($theData);
echo <<<JS
try { $recvFunc(eval('$theData')); } catch(err) { alert("XRPC Local error: " + err.description); }
$garbage
JS;
}
}
?>
In this example, I am simply returning the contents of the global php $_GET variable.
The results of the function look like this (broken up for readability)
try { myFunc(eval('{"uid":"1182389169957_0","h":"myHandler","theName":"theValue","anotherName":"anotherValue"}'));
} catch(err) {
alert("XRPC Local error: " + err.description); }
setTimeout('try {
temp=document.getElementById("1182389169957.0");
tempParent=temp.parentNode;
tempParent.removeChild(temp);
} catch(e) { };', 1000);
Note that this is completely viable JavaScript – that’s the important part. If this has a syntax error we have big troubles. Basically this script attempts to call <your handler> with a JSON version of the data I want returned. If there’s a problem, I alert with the error message in the first catch. Then I set a timeout for 1 second later to try and kill the node that contains the script. If it fails, it gives up quietly.
There’s really not much more to it than that. I am now retrofitting a bunch of code with this technique and am satisfied with it’s performance and stability. I welcome comments and flame on why I’m doing it wrong
Things that I should think about in the future* It probably needs a timeout and reissue or fail mechanism. Even thought the <script> tag is reliable, if there's a network problem and it doesn't come down, it needs a failover protocol.
/p
