5 ms·

Protobuf and FIDL have very different design goals though. One is meant for backwards compatible over the wire communication between loosely coupled RPC systems

Protobuf and FIDL have very different design goals though. One is meant for backwards compatible over the wire communication between loosely coupled RPC systems, and one is meant to be a highly efficient IPC. I expect, for example, that it is vastly more efficient to send a known datastructure over the wire in FIDL, but it is vastly more efficient to parse, modify/extend a repeated subfield, and then reserialize a protobuf. You can't "fix" a system to achieve two goals that are in conflict, sometimes it is in fact better to have N opinionated systems, than one that is only okay at everything.

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 ago
  Skimming 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 ago
    Other 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...
moltenguardian 5y ago
Are old applications going to run on new kernels? If so, backwards compatibility is a primary goal of an IPC dialog.
cmrdporcupine 5y ago
This difference in focus doesn't stop various teams at Google from forcing gRPC/Protobuf into use in places where an IPC system like Mojo/FIDL or even a simple wire protocol (JSON over WebSocket say) would be more appropriate. I know of at least 2 HW/embedded type projects at Google where major engineering had to be done for months because an upstream team refused to use anything but gRPC.
- surajrmal 5y ago
  Mojo and FIDL aren't necessarily portable outside of their respective platforms. grpc may have unnecessary overhead when used for IPC, but it's well supported, understand, and portable. I don't claim to understand the full constraints the teams you refer to were under, but I'd like you to consider that they may have done what they thought was best.
  - cmrdporcupine 5y ago
    Why would you assume I didn't consider?

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 ago
Skimming 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 ago
  Other 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...

moltenguardian 5y ago

Are old applications going to run on new kernels? If so, backwards compatibility is a primary goal of an IPC dialog.

cmrdporcupine 5y ago

This difference in focus doesn't stop various teams at Google from forcing gRPC/Protobuf into use in places where an IPC system like Mojo/FIDL or even a simple wire protocol (JSON over WebSocket say) would be more appropriate. I know of at least 2 HW/embedded type projects at Google where major engineering had to be done for months because an upstream team refused to use anything but gRPC.

surajrmal 5y ago
Mojo and FIDL aren't necessarily portable outside of their respective platforms. grpc may have unnecessary overhead when used for IPC, but it's well supported, understand, and portable. I don't claim to understand the full constraints the teams you refer to were under, but I'd like you to consider that they may have done what they thought was best.
- cmrdporcupine 5y ago
  Why would you assume I didn't consider?