Native JSON Parsing
Native JSON Parsing
The JSON format is widely used within Ajax applications, perhaps the most popular client-server data interchange format in use today. The JSON format was carefully architected with security in mind, and only supports "data" constructs and does not support any "logic" constructs, such as function definitions or assignment statements. However, except for Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=387522), today's browsers do not support native JSON parsers.
John Resig blogged about this issue, where he highlights the performance imperative:
Why Is This Important?
In this section, the contributors should express their opinions about this feature request, such as providing particular technical analysis or describing in prose why this feature is important (or not). It is recommended that each contributor create his own level-3 sub-section (e.g., === Jon Ferraiolo Comments ===).
Coach Wei Comments
great feature request. It is very slow to process large JSON objects (serialization, deserialization, etc) currently, especially when the JSON object reaches 50KB+ footprint. When you are building real apps, it is not uncommon to have data exchange in the order of 100KB or even more.
Krishna Sankar Comments
I assume we also want native js syntax like the for ..in et al as well as the parsing, John R mentions in his article. Could we think of any security artifacts ?
Brad Neuberg's comments
I think this should just be a part of the Better Security for Cross-site Scripts proposal. Native JSON parsing (and native secure-JSON parsing) seems like a subset of that.
Phase I Voting - Vote for Your Top 5 Features
NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:
Phase II Voting
More about this later.