FreeLists / openbeos / [openbeos] Re: A new BMessage implementation (Message4)

[mmlr@xxxxxxxx]

> Couldn't you use offsets into the table instead of indices?

For the hashtable you mean? Yes I could and I first had it that way. But
using an index is far cleaner in the end since the FieldsData buffer is
just a FieldHeader array:

FieldHeader *field = fFields[index]

> You could reserve an offset table at the beginning of a field
> chunk - when the table is full, you add another offset table and
> link it from the first table.

I don't quite understand what you are saying here. You mean for the
field data itself? Currently it has no offset table at all. Neither dos
R5 so they perform pretty much the same. Iteration is done in that case
(pseudo code):

uint8 *pointer = firstItem;
for (int32 i = 0; i < index; i++) {
    itemSize = *(ssize_t *)pointer;
    ...
    pointer += itemSize;
}

> Anyway, as long as we keep the R5 format on-disk, I would
> welcome this Message4 implementation :-)

Do we really have to? To ensure this we would have to always flatten
into a R5 format for the Flatten() function. The problem with that is
that in many cases you don't want to use Flatten only to store to disk.
In many places inside the Haiku source you also have Flatten() and then
the private SendFlattenedMessage() is used. This would essentially kill
the flatten/unflatten goal of Message4.
Be added a new Flatten() prototype in Dano to specify the target format.
Couldn't we just do the same and use the native Message4 format for the
Flatten() function?

Regards
Michael