A few years ago I wrote a “Flash connector” for the ArcIMS HTML Viewer. This “connector” took advantage of Flash’s security sandbox model, which allows cross-domain data connections under special, protected circumstances. The point was to allow ArcIMS to get around JavaScript’s “same-domain policy” limitation — to allow distributed web-map calls without a proxy.
Really the point was to put an ArcIMS HTML viewer on my HTML-only web-resume host, but I digress.
In the browser, ArcIMS’s JavaScript and Flash communicated via Flash’s “External Interface” methods. ArcIMS could post ArcXML to and from other domains. Flash’s security model requires a “crossdomain.xml” be published on the remote-domain. Jan Bliki’s excellent Flash + ArcIMS work at the EEA offered both the ArcIMS backend and “crossdomain.xml” to test all of this against.
The whole point, again, was to get around JavaScript’s ”same-domain policy” limitation. Fast forward to 2007 where JSON is commonplace. One accepted JSON paradigm is On-Demand Javascript – a special case where JSON-encoded data may be accessed across domain boundaries. Essentially, an HTML <script> tag may be dynamically generated in the DOM, thus loading the JSON data. There is some debate whether this is a feature, or a bug.
For a moment, I considered rewriting my “Flash connector” as a “JSON connector”. However, the lack of domain restrictions on DOM-based JSON requests does not apply to XmlHttpRequest JSON requests. This means that JSON data may only be loaded via an HTTP “GET”; you can “POST” information to remote domains. Hence, Javascript still cannot POST data to remote domains.
Overall? If you’re not interested in proxying, 2-3 year old Flash technology is still better than JavaScript. Why? The security model. Microsoft has been hinting at giving Silverlight a permissive cross-domain policy. I suggest they do so.
Let me know in the comments if there is any interest in me posting a “Flash-connector” walk-through.
