+1 for making it a compiler command-line option.
Pretty much all other IDLs get this wrong to some degree also.
Having annotations or options in the IDL file is nice, but make sure
they are only helping to define the message and the service, not the
implementation.
When I get a service
+1 for making it a compiler command-line option.
Pretty much all other IDLs get this wrong to some degree also.
Having annotations or options in the IDL file is nice, but make sure
they are only helping to define the message and the service, not the
implementation.
When I get a service
Sorry, I realize that wasn't a very clear statement...
What I mean is, if there is an option which does not leave any
fingerprint in either the serialized message or the
FileDescriptorSet, so that you can't tell how the option was set by
looking at either of these, then the option is controlling
I was reading through the code and I'm not sure I understand the
thought behing the ZeroCopyInputStream implementations.
It seems to me that if the underlying data source actually *is* a
stream to begin with, ZeroCopy does not perform any fewer copies;
using the copying adapter, it allocates an
Thanks for the quick response...
So, to do an RPC implementation over a stream channel (e.g. TCP),
where the message length is being sent in advance of the message body,
the fastest way would still be
(1) allocate bytes[length]
(2) stream.read(bytes, length)
(3) message.ParseFromArray(bytes,
