2

Is it possible to have two applications App-1 and App-2, one runs on OS-1 another on OS-2. App-1 serialises/deserialises data with nanopb and communicates with App-2. App-2 serialises/deserialises data with google protobuf and communicates with App-1.

Dimitri Ratz
  • 21
  • 2

1 Answers1

3

Yes. That's a major point of protobuf, being able to communicate with implementations in different languages. All protobuf libraries should be compatible with each other.

The specific case of nanopb vs. Google's C++ protobuf library is checked by nanopb alltypes test case, and the binary output is byte-for-byte equal for the two libraries.

jpa
  • 10,351
  • 1
  • 28
  • 45
  • So at the point of serialization/deserialization where the types are sequences of bytes they're one to one equivalent. They also share the same origins being compiled from the same `foo.proto` file correct? However they're programmatically different right, for example `pb_encode` vs `SerializeToString()` and `pb_decode` vs `ParseFromString`. So in general I can't rely on the same API to interact with each I take it. – jxramos Feb 11 '21 at 02:56
  • 1
    @jxramos Yes, having the API be equivalent across different programming languages would be quite difficult - some method names could be standardized but as is, they are not. – jpa Feb 11 '21 at 05:05
  • yah across languages would be a challenge for sure. The scenario I'm confronting is taking place in a single language. I'm writing a pybind library in C++ where I tried to use a macro that converts a c++ google protobuf to a python google protobuf for type interoperability between c++ and python runtimes. When I compiled I actually found I have a nanopb object and not a c++ google protobuf. The macro was written using `SerializeToString` and at that point I realized I assumed too much of the equivalence I thought was established between the nanopb and google protobuf entities. Good to know! – jxramos Feb 11 '21 at 05:21
  • 1
    Yeah. If nanopb were a C++ library, I would probably have mirrored Google's API. But it being pure C library, it made more sense to follow C style of API design. – jpa Feb 11 '21 at 11:27