Re: [mmox] Field names as numbers?

[Jon Watte <[e-mail]>]

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