Second Life JSON

We have a fairly new page in the Second Life™ wiki for the new JSON functions. If you do not know, JSON is used for moving data to and from web sites outside SL. Use of JSON should make applications simpler and more reliable.

See: JSON usage in LSL

5 thoughts on “Second Life JSON

  1. We got most of the kinks worked out, but I am still really annoyed with the “arbitrarily break JSON spec or even produce syntactically invalid output” feature if the string you try to serialize starts with a quote.
    For some reason, the highly specific use case of already having a JSON fragment stored in memory (dubiously signalled by starting the string with a quote) and still wanting to send it through a JSON serializer without double-encoding it takes precedence over the standard case of “reliably serialize my string variable per JSON spec”.
    I find that a highly annoying and brittle design choice, forcing workaround on the standard use, and introducing “magic switches” inside the protocol, which must be accounted for in all future implementations, both by LL in the server code and all users in consuming code.

    • When you say “We got most of the kinks worked out” does this mean “use at your own risk for now” or might production code be written at this point? My main concern is not how the implementation may differ from other standards and how those fixes might affect communication with other JSON aware apps but with using the JSON variable itself within LSL as a complex data type with “roll your own” object methods to manipulate it.

    • More specifically, LSL scripters have already started discussing such basic questions as to how to remove a KEY:VALUE pair from a JASON_OBJECT (http://community.secondlife.com/t5/LSL-Scripting/How-to-delete-a-JSON-object-s-member/td-p/2053663 ). Can we go ahead with working out these basic (but lacking in LSL) methods safely?

      • That is a hard one to answer. I can say the Lab had put the code out. That means they were prepared to support it. Usually you can count on them NOT changing what they have put out but instead changing it by adding to it.

        There is a 64BitXOR that didn’t work right. But, people wrote code based on it. The corrected XOR was named as a new function and the old one left in place. I can’t guarantee they will do the same with things in JSON. But, the chance is good and there is a record of that behavior.

        You can try to catch Kelly Linden at Tuesday’s noon meeting of the Server-Scripting user group and ask.

Leave a Reply

Your email address will not be published. Required fields are marked *