[sldev] message_template.msg ordering and packing : attentionLLfolks

[Ryan Williams]

John Plevyak wrote:
> Thanx Zero, if you are up in SF I owe you a beer (not to discuss
> silly semantics issues either).  Your right about std::map of course,
> the semantics demands key order iteration (which results in the standard
> std::map implementation to use the more costly red-black tree instead 
> of a simple hash).
> 
> A couple questions I didn't see answered in the transcript:
> 
> Is there going to be a LLSD Schema file as well? 
> (could it be the same file as the binary format Schema with an 
> encoding annotation?)
> 
> Is the new binary descripion going to include desriptions
> for things like ObjectData.Data in ImprovedTerseObjectUpdate?
> 
> Also, why use a string based API for the LLSD Message API 
> instead of, say enumerations?  Is this to support plugins or 
> is the overhead and possible typos just not issues?  

I may be misunderstanding your question, but it seems like this is
related to dynamically-typed versus statically-typed languages.  LLSD is
dynamically-typed, and enumerations are statically-typed.  There are
advantages to both.  Using your example, static typing helps alleviate
typo problems).  The advantage of dynamic systems is almost
philosophical: you can't rely on type checking being done for you, so
you write code that checks the incoming message contents, and fails
gracefully if it's not right.  Also you don't have to worry about the
client and server having the same enumeration (esp. given cross-platform
concerns).

If you want static type-checking in a dynamic system, you can just
define constants and use them instead of literals.

-RYaN

> If you want to wait 'till Tuesday we can chat then.
> 
> cheers,
> john
> 
> 
> 
> On Fri, Mar 16, 2007 at 11:41:54AM -0700, Mark Lentczner wrote:
>> Whew - there's a lot piled into this thread.  So I'm going to respond  
>> in sections:
> 
> ...
> 
> 
>