Re: [mmox] LLSD and content schema

[Jon Watte <[e-mail]>]

Meadhbh Hamrick (Infinity) wrote:
> <llsd>
>   <map>
>     <key>success</key>
>     <boolean>true</boolean>
>     <key>something_i_like_to_eat_on_sundays</key>
>     <string>bananas</string>
>   </map>
> </llsd>
>

IMO, that's a terrible serialization, because it depends on ordering. 
While XML is ordered, this particular serialization makes it hard to 
write XPath that selects "the string that comes after key success but 
before key something_i_like_to_eat_on_sundays".

>
>> If I want to send a piece of data from point A to point B, and point 
>> A and point B know exactly what this data will be, then data type 
>> information does not need to be sent as part of the serialization. In 
>> fact, including data type information is redundant and consumes 
>> network bandwidth unnecessarily.
>
> however, sending type information in the serialization allows 
> intermediary systems to reason about the content of the data they are 
> receiving and potentially make routing and caching decisions based on 
> the content.
>

I believe that, for the high-volume real-time binary stream, the 
bandwidth requirements outweigh the "caching" requirements -- nobody's 
going to be caching the real-time data anyway.

> LLSD is intended to be used in a "loosely coupled" environment. one 
> "feature" of such an environment is that systems be resilient in the 
> face of heterogeneity in terms of component version. for example, 
> consider a logging system that received logging messages from a number 
> of clients and stores them for later analysis. when the system is 
> initially deployed, messages may be defined as the tuple (source, 
> severity, description). it is not difficult to imagine the situation 
> where one

It turns out we have a logging system in OLIVE, and it stores the actual 
framed data without needing to know the internals at all. The clients 
need to know and understand the internals, but they can do that because 
they have the schema. Now, in OLIVE, the schema is described largely in 
code, not dynamically, as proposed in my proposal, but I think a dynamic 
schema is actually the right thing to do for interoperability -- it, 
too, makes it possible to update the protocol without recompiling 
anything. And it doesn't require sending "here comes a float" for each 
component of each position vector of each object in each packet sent...

I guess I don't see the applicability of LLSD. It's too little to be 
useful for a "verbose" format (like XML documents), and it's too much 
overhead for the real-time stuff. By contrast, XDR uses external schema, 
which is good, but the existing schema tools are not dynamic, which is 
less good. If LLSD can be adapted in one of two directions (or both!) 
then I'd be much less resistive. Either make it support external schema 
encodings in a binary efficient way (see 
http://www.interopworld.com/node/29) and use it for real-time stuff, or 
make it support proper, Xpath compatible XML and use it for the XML-RPC 
stuff.

Sincerely,

jw