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

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

mmlr@xxxxxxxx wrote:
> > 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]

Ah, so you only have to iterate over all fields when unflattening? (to 
create the fFields array)

> > 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;
> }

I meant for the field data, right. How iterating works now is clear, 
it's just a question of how often you have to do it (if such an offset 
table can make any sense).

> > 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.

Exactly, as you say: in *our* code and private methods. Those can 
easily be changed to use the new format.
BTW don't forget the new (and private) _kern_writev_port_etc() call 
when sending the message - that saves you creating a single large 
buffer to write into a port.

> 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?

Sure, we could do the same, but I never liked Be's solution there. The 
new Flatten() prototype is okay, and we should use it as well - but I 
don't like to introduce just another on-disk storage format for 
BMessages. Two different formats is already causing more headaches than 
necessary.
Also, for on-disk storage, the R5 format is more efficient.

Bye,
   Axel.