zbus-old
zbus-old copied to clipboard
dbus2
`Message` API should be able to handle non-native byte order
We should decode messages based on the byte order on the first header field, rather than error out on non-native byte order.
In GitLab by @elmarco on Jul 7, 2020, 17:29
Yes, that would make sense, I think. I am not sure genericity is really buying us much though.
I am not sure genericity is really buying us much though.
Maybe not for D-Bus, where we negotiate with the bus and it's extremely unlikely to fail if we're choosing native-endian. However, D-Bus over network (SSH) is not completely unheard of so if anyone use it there, they might need this feature.
Alternatively, we could just use whatever endian the bus says it supports and then it can all be handled internally, w/o any API changes. WDYT about this route?
In GitLab by @elmarco on Jul 7, 2020, 18:28
yes, if possible it should handle both cases internally imho. What I mean is that have <B> byteorder has a generic parameter isn't perhaps saving much compared to a runtime byteorder check & dispatch (while the benefit in term or binary code size & code complexity should be clear).
yes, if possible it should handle both cases internally imho.
Right. Then I'll change the scope of this.
What I mean is that have
<B>byteorder has a generic parameter isn't perhaps saving much compared to a runtime byteorder check & dispatch (while the benefit in term or binary code size & code complexity should be clear).
Well I was more thinking in terms of consistency with zvariant API. But we don't need to decide this if it's all going to be an internal logic.