reading and writing length delimited messages is part of the official implementations. [1] I don't understand the claim of "non-default". There are multiple ways to write protobuf data, and this is one of them. It's actually the only one I've ever used, because why would you not?
If your implementation doesn't support something in the reference implementation, that seems like your problem, not anyone else's.
> It's actually the only one I've ever used, because why would you not?
Because it’s not part of the protobuf specification, not part of a valid protobuf message, and framing is a transport/file format concern and should not be performed by default.
If someone is expecting to receive a protobuf-encoded payload, it must not include a framing header.
> If your implementation doesn't support something in the reference implementation, that seems like your problem, not anyone else's.
Someone else’s failure to follow the spec is not our problem.
OP just told you it was in the spec, and then linked you directly to it. You're just repeating your previous post without adding anything new. Here's a more direct link:
The result is not protobuf and doesn’t claim to be.
Looking at my employer’s protobuf runtime for our major programming language, we don’t even support it.