Re: optimize_for option default
+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 definition from a service author I don't want to be told how to optimize, or what namespace my generated classes should go into. Those things can be different for every client. As it is now, a client developer would have to mark up the .proto file that s/he received from the service developer. - Alex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: optimize_for option default
+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 definition from a service author I don't want to be told how to optimize, or what namespace my generated classes should go into. Those things can be different for every client. As it is now, a client developer would have to mark up the .proto file that s/he received from the service developer. - Alex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: optimize_for option default
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 only code generation and is not affecting the service contract. So it should not be in the .proto file. I think that applies to the package statement as well as optimize_for. Protocol Buffers does not put globally unique signatures into the messages or descriptors based on your package declaration. It only affects the code generation. - Alex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
ZeroCopyInputStream behavior
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 internal buffer, fills the internal buffer from the stream as needed, and then provides a ZeroCopy stream interface to that internal buffer. So, the amount of copying appears to be the same as if you read the stream into memory yourself and then called ParseFromArray. What am I missing? -- Alex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: ZeroCopyInputStream behavior
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, length) ... assuming that memory allocation for a large message is not a problem. true? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
