[protobuf] Regd: Resolving Wire type ambiguities
Hi, Thanks for the clarification. I did try one dirty method of finding the original types, because of my .proto-less situation. I relied on exception statements thrown out when I iterated through the protobuffers by trying to extract a known wiretype with a wrong-type getter. I know it sucks, but it worked for me. Thanks. Regards, Rahul Prasad On Mon, Nov 16, 2009 at 1:42 PM, Jason Hsueh jas...@google.com wrote: You can decode the protocol buffer with just wire type + tag number, but you won't know the original types without a proto definition. Everything would be treated as an unknown field. You could access these by iterating through the UnknownFieldSet, but again, you can't recover the original types. On Sat, Nov 14, 2009 at 1:10 PM, rahul prasad rahu...@gmail.com wrote: Hi Marc, Thanks for the clarification. If the actual .proto was there, i would not have posted that question [?] at the first place. Anyways, to decode a protocol buffer, is it not enough to have just the wire type + tag number combination? (except of course, handling of the sub-messages-ness and other ambiguities you mentioned below have to be done manually though) Regards, Rahul Prasad On Sat, Nov 14, 2009 at 3:57 PM, Marc Gravell marc.grav...@gmail.comwrote: If you treat it as a string (UTF8), you are likely to get garbage. If you treat it as a byte[], then you just get a BLOB - you don't lose anything, but you might not be showing some more detail that you could show. You could, however, check for likely-sub-message-ness - i.e. after getting the length, you could try decoding the next few bytes as a variant, and do the shift trick; see if it looks likely to be a sub-message etc; you could try to validate the entire string, see if it makes sense. Note that you don't have to store any of the data - just follow the rules for each wire-format until something doesn't look right or you've checked the string. Easiest, though, is to have the .proto available ;-p Marc 2009/11/14 rahul prasad rahu...@gmail.com Hi, As seen from the below wire types table from protobuf documentation, if i try to extract a value from a protobuf that is of type 2, it could either be a string, byte array or a embedded message etc, If I cast the value as bytes or string on the decoding side, while on the encoding side it was actually an embedded message, what would this result in? Will I be able to retrieve the actual value, someway or the other doing it this way? The available wire types are as follows: Type Meaning Used For 0 Varint int32, int64, uint32, uint64, sint32, sint64, bool, enum 1 64-bit fixed64, sfixed64, double 2Length-delimitedstring, bytes, embedded messages, packed repeated fields3Start groupgroups (deprecated)4End groupgroups (deprecated)532-bitfixed32, sfixed32, float Regards, Rahul Prasad -- Regards, Marc --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- inline: 347.gif
[protobuf] Regd: Z occuring between protobufs
If I try to grab and read the protocol buffer I populated, I see in the logs where I am outputting, characters like Z especially occuring at places where I had added another protobuf to the exisiting protobuf. Can you explain what it's purpose is and how does this occur? rahul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[protobuf] Regd: Resolving Wire type ambiguities
Hi, As seen from the below wire types table from protobuf documentation, if i try to extract a value from a protobuf that is of type 2, it could either be a string, byte array or a embedded message etc, If I cast the value as bytes or string on the decoding side, while on the encoding side it was actually an embedded message, what would this result in? Will I be able to retrieve the actual value, someway or the other doing it this way? The available wire types are as follows: Type Meaning Used For 0 Varint int32, int64, uint32, uint64, sint32, sint64, bool, enum 1 64-bit fixed64, sfixed64, double 2 Length-delimitedstring, bytes, embedded messages, packed repeated fields3Start groupgroups (deprecated)4End groupgroups (deprecated)532-bitfixed32, sfixed32, float Regards, Rahul Prasad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[protobuf] Re: Regd: Resolving Wire type ambiguities
Hi Marc, Thanks for the clarification. If the actual .proto was there, i would not have posted that question [?] at the first place. Anyways, to decode a protocol buffer, is it not enough to have just the wire type + tag number combination? (except of course, handling of the sub-messages-ness and other ambiguities you mentioned below have to be done manually though) Regards, Rahul Prasad On Sat, Nov 14, 2009 at 3:57 PM, Marc Gravell marc.grav...@gmail.comwrote: If you treat it as a string (UTF8), you are likely to get garbage. If you treat it as a byte[], then you just get a BLOB - you don't lose anything, but you might not be showing some more detail that you could show. You could, however, check for likely-sub-message-ness - i.e. after getting the length, you could try decoding the next few bytes as a variant, and do the shift trick; see if it looks likely to be a sub-message etc; you could try to validate the entire string, see if it makes sense. Note that you don't have to store any of the data - just follow the rules for each wire-format until something doesn't look right or you've checked the string. Easiest, though, is to have the .proto available ;-p Marc 2009/11/14 rahul prasad rahu...@gmail.com Hi, As seen from the below wire types table from protobuf documentation, if i try to extract a value from a protobuf that is of type 2, it could either be a string, byte array or a embedded message etc, If I cast the value as bytes or string on the decoding side, while on the encoding side it was actually an embedded message, what would this result in? Will I be able to retrieve the actual value, someway or the other doing it this way? The available wire types are as follows: Type Meaning Used For 0 Varint int32, int64, uint32, uint64, sint32, sint64, bool, enum 1 64-bit fixed64, sfixed64, double 2 Length-delimitedstring, bytes, embedded messages, packed repeated fields3Start groupgroups (deprecated)4End groupgroups (deprecated)532-bitfixed32, sfixed32, float Regards, Rahul Prasad -- Regards, Marc --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- inline: 347.gif
[protobuf] Retrieving data with field number and wire type
Hi, Is there a facility in protobuf library to retrieve data if the field numbers and wire types are known? If so how to go about this? Regards, Rahul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[protobuf] Regd: How do I represent java.util.Date in my .proto definition?
How do I represent java.util.Date in my .proto definition? Is this supported, or any other workaround for doing this? Regards, Rahul Prasad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[protobuf] Re: Difference between protobuf implementations
So, If I am developing for Android, should I use this protobuf library instead of the standard implementation present at com.google.protobuf? Will I encounter any problems mid way due to this switch? Any feedback would be greatly appreciated. Regards, Rahul On Tue, Nov 10, 2009 at 3:56 PM, Henner Zeller h.zel...@acm.org wrote: Seems to be part of Android http://www.google.com/codesearch?q=com.google.common.io.protocol.ProtoBuf On Tue, Nov 10, 2009 at 11:36, Kenton Varda ken...@google.com wrote: On Tue, Nov 10, 2009 at 7:28 AM, rahul prasad rahu...@gmail.com wrote: Hi, May i ask whats the difference between these two protobuf implementations? com.google.common.io.protocol.ProtoBuf.java I've never heard of this. Where does it come from? com.google.protobuf package classes This is the official implementation. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[protobuf] Re: Difference between protobuf implementations
I am in a situation, where the .proto files are not present for the Protocol
Buffers used in the application I am working on. Since the .proto files need
to be created, I was wondering if the following yellow highlighted numbers
should correspond to the same fields they stood for in the actual .proto
files which were used to generate the classes?
For example, -
old proto file:
package protos;
message Person {
required string name = 1;
optional string age = 2;
}
new proto file:
package protos;
message Person {
required string name = 2;
optional string age = 1;
}
will this throw error when trying to retrieve data?, so what would your
suggestion be in creating such a proto file when the original is not
present.
Regards,
Rahul
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
