New LSL llLinksetDataToJson() and llLinksetDataFromJson() functions.
dantia Gothly
It would be incredibly useful to have native support for loading and unloading JSON data directly to and from linkset data. Currently, working with complex structured data in linkset storage requires manually looping over every key and parsing or serializing data ourselves, which can be time-consuming and error-prone.
I'd like to propose the following four new LSL functions to streamline this process:
- llLinksetDataToJson()
Exports the entire contents of the linkset data store as a JSON-formatted string. This includes all key-value pairs written with llLinksetDataWrite().
- llLinksetDataFromJson(string json)
Parses a given JSON string and writes all key-value pairs into the linkset data store.
- llLinksetDataToJsonProtected(string password)
Works like llLinksetDataToJson(), but returns a password-protected version of the JSON. Useful when exporting data that may need to be stored or transferred securely.
- llLinksetDataFromJsonProtected(string json, string password)
Takes a password-protected JSON blob and writes the included key-value pairs to linkset data after verifying the password.
These functions would dramatically simplify working with complex or shared data sets across scripts or objects. They'd also make it much easier to support backups, duplication, synchronization, and version control of in-world configurations.
Log In
Moo Boo
Yes to more JSON functionalities,
No to loading 128KiB worth of memory into a 64KiB script
Peter Stindberg
I see massive memory problems there, since the capacity of LSD is way larger than available script memory. A solution would be to give the proposed functions a prefix or pattern for the keys to load/unload.
I also see a massive problem with nested JSON structures since that hierarchical structure would need to go into the key naming, and we're back to square one with parsing requirements.
Tornado Siren
I don't exactly agree with the verbiage of these proposed functions, as they don't match LSL convention, specifically the usage of "From", but the ideas themselves are solid and I wholeheartedly support this suggestion. I just prefer it stick with function names that fit the rest.