3 ms·
FIDL actually does make backwards compatibility a core concern. Being able to modify an existing type and allowing client and servers to continue to work when o
by surajrmal 5y ago
FIDL actually does make backwards compatibility a core concern. Being able to modify an existing type and allowing client and servers to continue to work when out of sync is achieved through a similar mechanism by which protobuf achieves it - a data type in which all members are optional.
That said, there are certainly many design decisions that FIDL does do differently because the constraints of the problems it tries to solve are different as you mention.
- nly 5y agoSkimming the docs, it looks like the heavyweight use use of "tables", much like Flatbuffers, seems to be the only mechanism for forward evolution of a protocol. Looks like "structs" you can only remove boxed fields by setting their references to null, but not add fields.
- surajrmal 5y agoOther types such as unions, enums, and bits also have properties that allow for evolution: https://fuchsia.dev/fuchsia-src/development/languages/fidl/guides/compatibility?hl=en#safe_changes_to_members https://fuchsia.dev/fuchsia-src/development/languages/fidl/g...