JSON is pronounced jay-sun. JSON is a text based way of representing data structures. Some think of it as an alternative to XML. It primarily was developed for use in JavaScript programming for transferring data across a network.
I suspect for many of us the arrival of JSON in the Linden Scripting Language (LSL) is a non-event. But, for scripters it is a big deal.
This week the JSON upgrades will be running on the RC channels, all three. The new stuff added to the LSL is:
- list llJson2List(string json)
- Converts the top level of the json string to a list.
- string llList2Json(string type, list values)
- Type is JSON_ARRAY or JSON_OBJECT
- Converts either a strided list of key:value pairs to a JSON_OBJECT or a list of values to a JSON_ARRAY
- string llJsonGetValue(string json, list specifiers)
- Gets the value indicated by specifiers from the json string.
- string llJsonSetValue(string json, list specifiers, string value)
- Returns a new json string that is the json given with the value indicated by specifiers set to value
- string llJsonValueType(string json, list specifiers)
- Returns the type constant for the value in json indicated by specifiers.
- Usage guide: Json_usage_in_LSL (added to Wiki 5/14 – today)
You may have noticed in there the mention of ARRAYS. That is a big thing. I’m not sure it is going to give us arrays as we have with other languages. But, it looks to be closer than the strided lists we use.
Provided this Release Candidate makes it past testing this week another set of JSON features will roll into the RC channels next week. No, no word on what those will be.
Kelly Linden is leading the JSON project. Questions on its implementation can be brought to him at the Tuesday Server & Scripting meetings in Denby.
Kelly says we are seeing JSON added to improve the ability to interface LSL with the larger web. The previous maintenance version expanded the content-type support of http-in and http-out which ties in with this JSON addition.
Wow. I had no idea that was in the pipeline. Very much welcomed! The best way to send and receive data to and from external webservers before was to use CSVs, which is very clumsy.
This should also help with storing data in scripts period.
But, from that description it’s all still dependent upon strided lists. LSL still sorely needs multidimensional arrays, and for best JSON support, a hash datatype. Doesn’t seem like this’ll ever happen though. I still wish the C# project wasn’t canned.
Bravo to Kelly and company though.
I was very stoked to see this, but unfortunately, the implementation is completely broken and does not obey JSON spec. Most notably, it does not recognize quoted field names, which will break compatibility with a *lot* of other implementations, and all handling of quotes is completely shot in general.
https://jira.secondlife.com/browse/BUG-2594
(or https://plus.google.com/u/0/115651166594579792799/posts/MJXPe9kHfb7 if you cannot see the jira)
Thanks for pointing out the problem. I really would like arrays.
The issues were imported as a “major bug”, so it seems we’ll get a more robust implementation.
It’s still only functionality to do the conversion to and from the JSON protocol, though, not extra data types in LSL.
But yeah, arrays and hashmaps have been at the top of my wish list for a very long time.
Yep…I have no idea how this is in RC. I experienced all the same things with:
default
{
state_entry()
{
llListen(1, “”, llGetOwner(), “”);
string json;
// Key: Invalid, missing quotations.
// Value: Invalid, LSL compiler escapes quotations at compile time.
json = llJsonSetValue(“”, [“key”], “Value with escaped \”double quotes\” and \’single quotes\'”);
llOwnerSay(json);
// Result: {key:”Value with escaped “double quotes” and ‘single quotes'”}
// Key: Valid, requires manual quoting.
// Value: Invalid, LSL compiler escapes quotations at compile time.
json = llJsonSetValue(“”, [“\”key\””], “Value with escaped \”double quotes\” and \’single quotes\'”);
llOwnerSay(json);
// Result: {“key”:”Value with escaped “double quotes” and ‘single quotes'”}
// Key: Valid, requires manual quoting.
// Value: Escaping \ produces compile error.
// json = llJsonSetValue(“”, [“\”key\””], “Value with escaped \\”double quotes\\” and \\’single quotes\\'”);
// Result: Won’t even compile
}
listen(integer channel, string name, key id, string message)
{
// With valid JSON: {“key”:”Value with escaped \”double quotes\” and \’single quotes\'”}
llOwnerSay(llJsonGetValue(message, []));
// Spits out valid JSON
// Result: {“key”:”Value with escaped \”double quotes\” and \’single quotes\'”}
// With valid JSON: {“key”:”Value with escaped \”double quotes\” and \’single quotes\'”}
llOwnerSay(llJsonGetValue(message, [“key”]));
// Doesn’t recognize unquoted key
// Result: JSON_INVALID
// With valid JSON: {“key”:”Value with escaped \”double quotes\” and \’single quotes\'”}
llOwnerSay(llJsonGetValue(message, [“\”key\””]));
// Requires escaping valid quoted JSON key. Spits out a valid JSON string though.
// Result: Value with escaped \”double quotes\” and \’single quotes\’
}
}
Most of the issues have to do with compile time character escaping. At runtime a script doesn’t escape any characters so receiving proper JSON strings from a server is fine.
No idea why fields aren’t properly surrounded in quotes. If they fix that, the compile time issues with character escaping are easily worked around since I don’t think there’ll be many use cases where valid JSON strings need to be hardcoded.
And ignore the single quote stuff, doesn’t need escaping and is invalid JSON.
Add a JIRA…
You mean duplicate what Tali already reported that I could at best comment on here because they’ve made it impossible to see and comment on there? Yeah I did before.
As mentioned, Maestro imported it, and we’ve bounced some comments, primarily:
Single quote is in fact not per spec, and field names should be double-quoted (or at the very least handle when they are).
Maestro is unsure whether the functionality should handle escaping strings which contain quotes, or throw an error (leaving the escaping to the LSL script). I *strongly* believe it should handle escaping; it should not be necessary to “pre-mangle” a string into what is essentially a different string before sending it over a carrier protocol; if you have a valid string in one language, send it over the protocol, and write it in another language, it should be the same string. Please convince Maestro that this is the case 🙂
Tali, if you want to convince Maestro of anything, talk to him. The more people he hears from on the point the more likely he is to make changes.
Also, I think it is Kelly Linden that is leading the project.
Kelly handles LSL in general, AFAIK, but Maestro was the one commenting on the jira.
My point was, indeed, “the more people, the more likely”; just that I’m already counted, having jira’ed it and commented there.
It seems they listened. In response to my bug report of the same thing, Maestro said the two changes would be addressed in the next RC release. Hopefully all will be well then.
That’s optimistic… 🙂
Pingback: Wondering Around Second Life and the Web | Nalates' Things & StuffNalates’ Things & Stuff