GVariant format support
As we've always planned. The spec is here. For primitive types it's exactly the same so it shouldn't be very hard. For container types and strings, the most important difference is that GVariant keeps metadata at the end, not beginning.
We should test against glib's API to ensure compatibility and maybe also compare the performance diff, if any. Some very WIP work exists in this branch: https://gitlab.freedesktop.org/zeenix/zbus/-/tree/wip/gvariant
Checklist:
-
Ensure we always encode and decode in the right byte-order. -
Deserializer code for container types must deserialize from child value from their respective slices only. This likely means separate Deserializer instance(s) for child values. -
Deserializer assumes byte slice contains only the type currently being decoded, for basic types, this is only relevant to string (including signature & object path) deserialization. -
Support for Maybe type, which should map nicely to Option<T: Type>
-
(OPTIONAL) It would be great if we could also add integration tests against Ostree.
Edited by Zeeshan Ali Khan