-
Notifications
You must be signed in to change notification settings - Fork 6
Differences between MiniPB and Official Protobuf
Despite being mostly compatible with Protobuf, there are several cases where MiniPB works differently than Google's Protobuf implementation. Some of these differences or incompatibilities might be temporary.
Probably the most obvious one. MiniPB only supports the more light-weight (yet specific to MiniPB) format strings and key-value format list natively. Although adding protoc support is theoretically possible it is not yet implemented.
As per the official Protobuf documentation on encoding, packed and non-packed repeated fields must be cross-compatible. Due to implementation constraints this is not yet possible with MiniPB and attempting to deserialize such messages will result in an error condition.
This is not possible on Google's Protobuf due to cross-compatibility between packed and non-packed repeated fields. Otherwise there will be no way to differentiate between a packed field that has multiple values and a non-packed field that has multiple values. This is however currently possible on MiniPB. Use of this "feature" is discouraged.
In MiniPB, all vint-based types except for ones based on signed 2's complement encoding (i.e. type t and derivatives) can have arbitrary length. Meaning you can theoretically store things like an RSA 2048 public key inside type V fields. This is, however, obviously not supported on Protobuf since Protobuf attempts to map vints to native integer types. Handling of over-sized integers also does not seem to be well defined in official Protobuf documentation. Therefore when maximum compatibility with Protobuf is desired, it is recommended to use only 32-bit or 64-bit numbers or bitmask the numbers to be within 32-bit or 64-bit range before serializing.
Protobuf field groups (group <name> { ... }) are officially deprecated and MiniPB doesn not implement support for groups and the required field types (3 and 4).
Protobuf assumes the length field of bytes (and also encoded strings) can fit into a unsigned 32-bit integer. Therefore the maximum length of bytes and encoded strings are 2**32 bytes long. MiniPB however does not enforce this and can encode/decode bytes and strings of arbitrary length as long as the Python implementation and free memory allows. (See also Over-sized vint)
Currently all unknown fields will be discarded and no API exists to retrieve them.