[haiku-commits] Re: haiku: hrev52551 - headers/os/codec src/kits/codec
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 19 Nov 2018 08:44:05 +0000
19 novembre 2018 09:35 "Dario Casalinuovo" <b.vitruvio@xxxxxxxxx> a écrit:
Did you ever considered that all that could work on key-value pairs and we
the data, by reading and writing in a ordered way?
Instead of doing :
One could do (having the call order as a constraint):
This is how the app_server link works, and I find it less convenient for the
generic use case.
Being able to explore a message allows us to work in completely generic ways.
in clipboard or drag and drop cases, where you have no idea what the user is
trying to drag
and drop: text clip? archived BView for a replicant? rgb_color? image? media
file as an
entry_ref? Custom data internal to the app?
Moreover, the key-value system allows more freedom in evolving existing
messages (you can
deprecate one key and introduce a replacement, for example).
So, hardcoded sequential keys are convenient for an internal protocol where
matter (you can replace a key or add/remove keys as long as the sender and
kept in sync), and in cases where you can really be sure it won't ever change.
It is also nice that the BMessage is self-documenting with string keys, both
(you can explore an unknown BMessage in debugger for example), and for reverse
(when used as a fileformat or for network communications, or even when trying
with an existing app by sending it messages).
I would find BMessages with integer keys less convenient to use for these
reasons. I don't
have an opinion on your use in Media, I have to think about it more and explore
container format needs (I think Matroska can get pretty crazy with the metadata
to store, for example?)
Other related posts: