Javascript getXDM或JSONP使用哪一个来规避同源策略

我正在创建一个JavaScript小部件，它从我托管的WCF服务中获取大约4-6KB的数据，并使用画布标记（HTML5）绘制一些图表。我希望任何人都能够通过复制粘贴一些我共享的html和JavaScript，将这个小部件嵌入到他们的网站中

现在的问题是：同源策略，它不允许从小部件的主机域向我的域上的WCF服务发出任何XHR请求，这意味着任何使用小部件的人都无法从我的WCF服务获取数据（每个请求都会得到大约4-6kb的数据作为响应）

我在本网站上浏览了之前的内容，找到了以下可能的解决方案：

JSONP（可与我的WCF服务一起使用）

隐藏的iFrame（不可能，因为我无法控制这两个域）

window.postMessage（不确定JavaScript库是否能在旧浏览器（如IE6）中工作）

跨源资源共享（CORS）（不可能，因为我希望能够使用旧浏览器，如IE6）

反向代理方法（不可能，因为我无法控制用户网站的服务器）

easyXDM（可能是一个可行的解决方案，但需要探索如何将其与我的WCF服务一起使用）

首先，我想向大家确认，我对各种可能的方法所做的简要分析是正确的，我没有遗漏任何人正在使用的伟大解决方案，如果我的分析是正确的，我想讨论这些方法的优缺点

---

其次，我知道Facebook、Twitter和Google都在分享他们的应用程序（正是我想分享的方式），并且已经克服了这个问题。为了做到这一点，有谁能告诉我他们是如何解决这个问题的。这是你需要判断的

• 您的小部件（包括库）可以接受的大小
• 您需要轮询该服务的频率，或者该服务是否为一次性事件
• 完全浏览器兼容性对您来说有多重要

对于您描述的特定用例，我建议使用JSONP。它将保持小部件非常小，是一个很好的跨浏览器解决方案，可以处理适度的数据需求

---

Google etc使用“comet”类型的解决方案，在这种解决方案中，在客户端和服务器之间持久化类似套接字的流。这不应该用于小部件，因为它会占用浏览器资源。

easyXDM可以很容易地适应这种情况——只需看看xhr/CORS示例。但根据您的描述，我可能会选择JSONP，因为它的成本更低。但是如果你打算扩展这个小部件，那么easyXDM绝对是一个不错的选择——你提到的网站遵循easyXDM促进的相同模式（Twitter甚至使用easyXDM）。在我自己研究过之后，你已经在列表上找到了所有值得一看的东西。正如leeeb的回答在prob JSONP之间指出的那样。那还是容易的事。