the design:
JSONP is a very simple design pattern, you just set up communication via script tags and set sources to the target url from which you want to retrieve data. The returned data is then padded around a padding function you provide to the source url scheme or a function you have in prior negotiated/configured with the server.
example:
a script tag to return the user no. 1234 in the padding function returnedFunc would look like this:
<script src="http://other-domain.com/return/user/1234/returnedFunc" />
the return of this would be something like this:
returnedFunc( {"name":"Mike","id":1234,"greeting":"etc..."} )
so each JSONP call translates to a function call.
the problem:
My personal problem with this pattern is that you have to expose at least one method to the global name space which immediately raises concerns if you are working from the perspective on which basiin was developed, ie: creating a framework that will be invisible to the site it is installed on in order to facilitate building rich and save applications for bookmarklets.
Initial comments:
CORS actually does the job of cross domain data transfer just fine (and is much more efficient over url strings for sending data across domains). When I initially had developed the basiin transfer template I only had heard of it and actually had misinterpreted the Access-Control-Allow-Origin header as being required to be set by the resident server and not the remote server.
the design:
CORS or Cross-Origin Resource Sharing is an extension to the XHR request and actually a very good candidate to be used in a toolset as is basiin. The theory is that you just extend the capabilities of browsers to do XHR requests to domains that respond with an Access-Control-Allow-Origin header that either is * (meaning everyone) or contains the resident domain in it's string.
For clarification: resident domain/server is the domain on who's web page the browser is at and remote domain/server is the domain to which you are doing XHR requests.
the problem:
CORS by design doesn't send cookies and some browsers (even IE 9 as of lately) don't support send Access-Control-Allow-Credentials. CORS is a new and a bit fragmented technology atm, the ridiculous IE doesn't support it or supports it quite badly, many mobile devices don't support it, etc.
The fact is that I am actually thinking of integrating CORS into the basiin transfer object and only have it fall back to script.src based comms in case CORS is not supported but as the weathered observer might point out it is going to be a pigs job hacking CORS on top of the existing model, since the back end will have to also be extended. On the other hand performance atm, even with tmpfs/ramfs incoming directories is a pig as well. So a small bloat in codebase might actually be acceptable if you consider the fact that apache tends to stall after offering circa 1k responses to basiin in less than 30 seconds with the existing method.