On Fri, 04 Jan 2008 23:25:26 +0100, Close, Tyler J. <[EMAIL PROTECTED]>
wrote:
So, strictly speaking, the above is not true. It is not possible to
simply place a JSON file on a server and in so doing make it available
for cross-domain requests using the proposed XMLHttpRequest extension.
Indeed, you would have to use an HTTP header.
I believe that this WG has stated that this minimal level of control
over the server is one of the required deployment scenarios; but that
functionality is only supported for XML.
Currently, yes. We might revise this in future versions based on feedback.
Similarly, the JSONRequest proposal only supports this functionality for
JSON. Both proposals can tunnel other Content-Types within their
supported Content-Type.
You failed to reply to the XSLT and XBL remarks that the JSON thingie does
not address. These are important use cases. The access control proposal
can also be used for the server sent events protocol as proposed by HTML5.
JSONRequest would again fail to address that use case.
* Having multiple network APIs seems like a bad idea.
The two proposals have made opposite choices on fundamental design
decisions, such as: where policy is enforced, whether or not cookies are
sent, and whether or not interoperation with existing resources is
supported.
We got feedback that sending cookies and authentication data is *very*
important.
Any one of these choices could prove significant to adoption. For
example, some developers may require better support for other
Content-Types; whereas some organizations may be reticent to allow
installation of browsers that may interoperate with existing web
resources in unanticipated ways.
The access control proposal does not interoperate with existing web
content in unanticipated ways. The policy is *opt-in*.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
