[sldev] [AWG] Why the LLSD notation format should be thrown out

[John Hurliman]

Why the LLSD notation format should be thrown out:

* It mixes strings and raw binary data. One of the two binary 
serializations looks like this: b(13)"thisisatest", where thisisatest is 
raw binary data. Notice that it encloses the data with quotes, even 
though it is raw binary and not an escaped string. It also includes the 
two quotes in the byte length even though it is not part of the original 
data (so in code it looks something like int len = myByteArray.Length + 
2;). The entire rest of the format uses strings, so a UUID is 32 
characters plus the hyphens instead of 16 bytes. A parser has to either 
constantly convert small byte arrays into strings and parse the strings, 
or convert the entire thing to a string and convert the binary parts 
back to byte arrays.

* It puts implementation-specific details in to protocol. The only 
purpose of notation format is to provide something that is human 
readable. While this may be useful for debugging, there is no reason two 
separate machines need to exchange data in a human readable format. If 
you wanted, the XML serialization of LLSD is perfectly readable for 
anything except binary data, and a local pseudo-markup can be used to 
create a human readable format (for example, in libsecondlife we 
originally used an ASCII-art tree structure). Forcing LLSD 
implementations to agree on this format makes implementation and unit 
testing more tedious, and means it will sneak its way in to the protocol 
in places it should not be such as how the current XML-RPC login 
exchange uses small bits of it.

* It is the most difficult of the three formats to implement in code. 
The binary format is very straight-forward to implement and very 
efficient (speed-wise) to parse, and the XML format is easily 
implemented by piggybacking on top of an existing XML library. The 
notation format involves the most branching of code paths in the parser 
and has the most formatting options for the serializer, along with the 
aforementioned issues of converting back and forth between binary and 
string data.

John Hurliman