This page is a collection of notes regarding the proposed JSONRequest APIs. The Dojo Foundation considers this work to be incredibly important. We appreciate Yahoo's leadership in exposing their APIs for cross-domain usage and look forward to a future when browsers truly are first-class application construction platforms that safely tie potentially unrelated services together in ways that provide value to users.

The original JSONRequest proposal can be found at: http://json.org/JSONRequest.html

Variously, Dojo contributors have made the following notes:

1. The proposed APIs do not expose an independent, high-speed JSON encoding/decoding functionality despite it being at the core of any system that implements JSONRequest. Having such an API would help to drive the adoption of JSON and reduce depenendcy on eval() in many systems.
2. The calling convention of the JSONRequest API differs significantly from the XMLHTTP interface. Since this is perhaps the best-known request/response interface exposed to scripting, following it's "object per connection" semantics might make the API feel more comfortable.
3. Even after significantly discussion, it's clear that a credible case has been made for supporting JSON as the only possible encoding for this transport mechanism.  Multiple responders have suggested that allowing plain-text response parsing would be significantly valuable.
4. If allowing plain-text responses is considered to be dangerous because of the ability to query "uncooperative services", then exposing a service via JSON as the only key to determining "cooperativeness" seems like so much "security through obscurity". Examples such as Macromedia's cross-domain "can query" file perhaps point to a better solution if explicit server cooperation is viewed as critical. We're aware of the shared-hosting problems, but if JSONRequest becomes ubiquitious, then we expect the "must be JSON" barrier to entry to be ephemeral at best.
5. The no-cookies policy is seen as beneficial.