- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 03 Oct 2007 15:36:56 -0700
- To: Ric Johnson <ricjohnsoniii@gmail.com>
- CC: public-appformats@w3.org
Ric Johnson wrote: > I have a few questions for the new draft: > > Is this really required? I can achieve the same with > a) Dynamic script tags (JSON requests) as long I am am comfortable with GET Current JSON solutions require that you point a <script> element at a remote server, thereby letting the server execute any javascript in the security context of your page. This is not always desirable. Second, JSON only works for script-initiated loads. It can't be used to allow cross-origin loads of things like XSLT stylesheets, XPath document() loads, XBL bindings, etc. > b) PROXY governance This is much slower as it requires two network transfers, one from the UA to the proxy, one from the proxy to the destination site. It also requires server support. > c) CNAMEs as a way to bypass the domain restrictions This also requires server support, on both the requesting and the requested end. A site that wants to support getting requests from anyone would likely have to dedicate an IP number for public APIs. > Other issues: > a) No only does the browser have to allow this, but XMLRequest does as well. What is the difference? The browser implements XHR. > b) What about <a href="http://json.Com">JSON</a> responses? XML is > great, but let us not fall into the "Not invented here" trap Agreed. XML isn't the end-all be-all format for data trasfers. Neither is JSON. So why not support both. Additionally, access-control can be used for formats other than XML as there is a http-header. / Jonas
Received on Wednesday, 3 October 2007 22:38:01 UTC