Bob Sneidar wrote:
> Richard I think I hear you say that JSON is an alternative to
> arrayEncode?
I'm apparently writing so badly maybe I should skip the shorthand "LSON"
and just write the full form: "output from LC's built-in arrayEncode".
I'd adopted "LSON" to help position its role as the LC-native way to
transport and store array data, similar to the role of JSON in
JavaScript workflows or BSON within MongoDB systems.
When you need interoperability, there's no longer much of a choice: JSON
is the de facto standard. Though highly specific to how JavaScript
works, browsers are so ubiquitous that most languages other than
JavaScript now have some means of transforming JSON into a format that
can be used internally, as LC does with its JSONtoArray and ArrayToJSON
functions.
But when all producers and consumers of data in a system use the LC
engine, LSON (output from LC's built-in arrayEncode) is the
with-the-grain choice.
> What about storing to SQL blob and binary files? Will it suffice? I'd
> consider converting all my arrayEncoding to JSON if so.
LSON (output from LC's built-in arrayEncode) is a binary format, so any
storage or transport mechanism suitable for binary data can be used.
--
Richard Gaskin
Fourth World Systems
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
