LLSD

The LLSD flexible data system

The following text is from the comments in the source of the file: linden\indra\common\llsd.cpp

Summary

LLSD provides a flexible data system similar to the data facilities of dynamic languages like Perl and Python. It is created to support exchange of structured data between loosly coupled systems. (Here, "loosly coupled" means not compiled together into the same module.)

Data in such exchanges must be highly tolerant of changes on either side such as: - recompilation - implementation in a different langauge - addition of extra parameters - execution of older versions (with fewer parameters)

To this aim, the C++ API of LLSD strives to be very easy to use, and to default to "the right thing" whereever possible. It is extremely tollerant of errors and unexpected situations.

The fundimental class is LLSD. LLSD is a value holding object. It holds one value that is either undefined, one of the scalar types, or a map or an array. LLSD objects have value semantics (copying them copies the value, though it can be considered efficient, due to shareing.), and mutable.

Undefined is the singular value given to LLSD objects that are not initialized with any data. It is also used as the return value for operations that return an LLSD,

The scalar data types are:

• Boolean - true or false
• Integer - a 32 bit signed integer
• Real - a 64 IEEE 754 floating point value
• UUID - a 128 unique value
• String - a sequence of zero or more Unicode chracters
• Date - an absolute point in time, UTC, with resolution to the second
• URI - a String that is a URI
• Binary - a sequence of zero or more octets (unsigned bytes)

A map is a dictionary mapping String keys to LLSD values. The keys are unique within a map, and have only one value (though that value could be an LLSD array).

An array is a sequence of zero or more LLSD values.

Scalar Accessors

Function: Fetch a scalar value, converting if needed and possible.

Conversion among the basic types, Boolean, Integer, Real and String, is fully defined. Each type can be converted to another with a reasonable interpretation. These conversions can be used as a convenience even when you know the data is in one format, but you want it in another. Of course, many of these conversions lose information.

Note: These conversions are not the same as Perl's. In particular, when converting a String to a Boolean, only the empty string converts to false. Converting the String "0" to Boolean results in true.

Conversion to and from UUID, Date, and URI is only defined to and from String. Conversion is defined to be information preserving for valid values of those types. These conversions can be used when one needs to convert data to or from another system that cannot handle these types natively, but can handle strings.

Conversion to and from Binary isn't defined.

Conversion of the Undefined value to any scalar type results in a reasonable null or zero value for the type.

Automatic Cast Protection

These are not implemented on purpose. Without them, C++ can perform some conversions that are clearly not what the programmer intended.

If you get a linker error about these being missing, you have made mistake in your code. DO NOT IMPLEMENT THESE FUNCTIONS as a fix.

All of thse problems stem from trying to support char* in LLSD or in std::string. There are too many automatic casts that will lead to using an arbitrary pointer or scalar type to std::string.

Questions & Things To Do

Would Binary be more convenient as usigned char* buffer semantics?

Should Binary be convertable to/from String, and if so how?

• as UTF8 encoded strings (making not like UUID<->String)
• as Base64 or Base96 encoded (making like UUID<->String)

Conversions to std::string and LLUUID do not result in easy assignment to std::string, LLString or LLUUID due to non-unique conversion paths.