On Mon, Nov 19, 2018 at 9:44 AM Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
wrote:
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 andwe could deprecate
"finding"
the data, by reading and writing in a ordered way?
i.e.
Instead of doing :
foo->FindString(...)
foo->FindBool(...)
One could do (having the call order as a constraint):
foo->ReadString()
foo->ReadBool()
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. For example,
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 ABI/API doesn't
matter (you can replace a key or add/remove keys as long as the sender and
receiver are
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 for debugging
(you can explore an unknown BMessage in debugger for example), and for
reverse engineering
(when used as a fileformat or for network communications, or even when
trying to cooperate
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 what each
container format needs (I think Matroska can get pretty crazy with the
metadata they allow
to store, for example?)
