[sldev] message_template.msg ordering and packing : attentionLLfolks

[John Plevyak]

Agreed.  What we need is a standardized protocol specification which
can be implemented without reference to other code.  The current
message_template.msg file is not that for a number of reasons:

- the version number doesn't rev when the protocol changes
- it doesn't provide encodings (binary/XER/ASN.1/XMP-RPC)
- it doesn't cover everything, e.g. the critical Data portion of ImprovedTerseObjectUpdate 
- it doesn't handle variant records (e.g. the Data portion of ImprovedTerseObjectUpdate)
- it doesn't describe message semantics

I am going to go to Zero's office hours, I hope I can see some of you
with the good ideas there.

john

On Fri, Mar 16, 2007 at 08:26:47AM -0700, John Hurliman wrote:
> Rob Lanphier wrote:
> >Zero Linden (Mark Lentczner) is currently holding office hours regularly
> >in world...see his email from yesterday.  A bunch of folks from LL are
> >working on big protocol improvements, exactly along the lines that you
> >describe.
> >
> >Hopefully we can bridge the gap between the email discussion going on
> >here, and the work that he's doing there.  Best thoughts on how to do that?
> >
> >Rob
> 
> The LLSD serialization/deserialization as it is proposed in Zero's 
> diagrams is built on top of the message_template.msg system instead of 
> replacing it (such as the CAPS system mostly does). It doesn't address 
> the fragile and obscure field/block ordering in the template file, and 
> real-time lossy packets like AgentUpdate will always be vulnerable to 
> field/block reordering. While the LLSD serialization, CAPS system, and 
> all the new protocol stuff going on is really interesting, it doesn't 
> make the original issue brought up in this thread go away. The two main 
> issues I see in this thread are simplifying the protocol in to something 
> documentable (imagine writing protocol documentation that says "throw 
> all of these in to a std::map and the results will magically be 
> produced. Wait, you're not using C++ and the STL to implement the 
> protocol? Oh... that's too bad") and hardening the real-time lossy part 
> of the protocol against future changes (is moving away from the 
> all-or-nothing approach of comparing a hash of the message template 
> desirable, and how do we do it). Those two goals may or may not be 
> related, and everyone likely has different feelings on how important 
> each one is.
> 
> John Hurliman
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html

-- 
John Bradley Plevyak, PhD,   jplevyak at acm.org,   PGP KeyID: 051130BD