Subject: [mmox] Field names as numbers?

From: Catherine Pfeffer <[email-masked]>
Date: Thu, 26 Feb 2009 14:59:22 +0100

> Does the current binary encoding encode the actual names and types of
> properties before sending the values?

It does not encode them *before* sending them. It intermixes the data, the
data types and the field names. The data is always next to its type and next
to its name.

> If so, you could probably cut out
> at least half, if not more, using the separate schema method.

Yes we could. Yes it would be a significant bandwidth win.

I am not sure I like this idea of replacing keys like "Nose_Orientation"
with numbers like 443:
 - a protocol dump would be harder to debug (you'd need a table to know what
each field means).
 - it would be less simple in a program because you would need to look up in
a table to solve the indirections
 - it is error prone (it is easier to mix field 443 with field 442 than to
mix field "Nose_Orientation" with field "Associated_Sound")
 - if you have been unable to transmit the packet containing the table, you
can't do anything anymore
I have very bad memories of ISO 2709 (http://en.wikipedia.org/wiki/ISO_2709)
which also takes the "tags are numbers" approach.

But I realize the reasons above are somehow weak. With such a reasoning, we
would not use schemas with XML files either. Perhaps Infinity has better
arguments pro or against it.

-- 
Cathy

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 10:58:54 -0800

Catherine Pfeffer wrote:
> I am not sure I like this idea of replacing keys like 
> "Nose_Orientation" with numbers like 443:
>  - a protocol dump would be harder to debug (you'd need a table to 
> know what each field means).

Agreed. Another example is MPEG video, or JPEG images: you can't see the 
color of the individual pixels inside Wireshark.

>  - it would be less simple in a program because you would need to look 
> up in a table to solve the indirections

I don't think that's intellectually honest. Usually, doing a look-up 
from integer to "something" is a lot faster than doing a look-up from 
string to "something." If you are saying that you'd need to do a look-up 
from integer to string, and then from string to something, then I 
suggest that perhaps your internal structure could be improved :-)

>  - it is error prone (it is easier to mix field 443 with field 442 
> than to mix field "Nose_Orientation" with field "Associated_Sound")

Who would do this mixing? The code? The code works, or it doesn't. To 
code, the values 17 and 443 are as different as 442 and 443.

>  - if you have been unable to transmit the packet containing the 
> table, you can't do anything anymore

If I can't send data, I can't send data, that's right! If I can't send 
data, why am I trying to do a live, real-time streaming application anyway?

Note that I am not proposing using schema-driven binary interchange for 
transactional or durable applications. I believe we need at least two 
separate systems: a very efficient transmission format for streaming 
live, high-bandwidth data (such as a stream of entity property updates 
during simulation), and a very robust exchange format for transactional, 
batch or offline processing (such as "properly structured" XML).

Sincerely,

jw