Re: to be effcient or not to be efficient

Steve Lhomme wrote:
> Consider this :
> struct _blah {
>     uint16 Size;
>     uint8  FieldA;
>     uint32 FieldB;
>     char   FieldC[30];
> };
> 
> Now (after a few years) you realise that you need FieldA to be on 2 
> octets instead of 1. You simply can't. And you can with EBML.

BTW, my point is that plain C structures are too simple to have good 
backward/forward compatibility.

But I understand that EBML is too complicated for what we need. What we 
need is a "classic" TLV system : [Type] [Length] [Value]. EBML is a 
special TLV because the Type and Length have variable length. We don't 
need this here. I think we just need the Type on 2 or 3 octets (2 should 
be enough) and the Length on 4 octets (handle up to 4GB of data).

Then as for EBML, each Type (ID) would have its own meaning and type : 
uint, sint, float, date, string, unicode string, custom, Master. The 
Master type means that it contains other IDs. This way you could have :

[MessageID][Length][
	[FieldA][Length][Value]
	[FieldB][Length][Value]
	[FieldC][Length][Value]
]

Of course it depends if you prefer compatibility more (or less) than 
speed. But as a communication means, it's more general. Then internaly 
you are free to use structs directly. You just then have to convert the 
data between the struct and the "EBML" data when you need communication.

Passing a message in such a way would also contain the data directly. 
You just pass a pointer to the "Message ID" buffer. Instead of Message + 
Data + Length of data.