> That makes no sense. If the bytes were the same, how would deserializing
> them be able to produce unequal messages?
Yes, I guess if we can rely on the canonical ordering of the fields,
that should be enough.
> If possible, I would recommend designing your application such that it only
> requ
--~--~-~--~~~---~--~~
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...@googlegroup
The main complexity arises from several instances of nested types
(which can be arrays). The protos below are not complete but should be
sufficient to give you the design in use here.
The 1st proto is complete. 2nd proto is much more detailed. I too was
thinking about reflection but without a ba
On Tue, Sep 29, 2009 at 12:41, alopecoid wrote:
>
>> Given that the serialized bytes have to be able to *deserialize* back
>> to the original messages, surely if those original messages aren't
>> equal, the serialized forms would have to be different too - assuming
>> we're talking about the same
Well... how complex is the data? Reflection seems the most obvious
choice if it is available - especially since that will work well with
things like PropertyGrid (if you are in winforms). If I understood the
scenario better I may have more ideas...
Marc
On Sep 29, 6:39 pm, "test.f...@nomail.plea
On Tue, Sep 29, 2009 at 12:41 PM, alopecoid wrote:
> But, as in my example, that doesn't seem to be the case (necessarily).
> Again, for example, let's say you have two messages, both of the same
> type. The proto defines two optional fields, both of type variable
> int64.
>
> Say message A poopu
On Tue, Sep 29, 2009 at 12:22 PM, alopecoid wrote:
>
> Hi,
>
> Can serialized messages be used reliably as keys?
>
> In other words, is it guaranteed that...
>
> - Two equal messages will always generate equal byte sequences?
> (Are fields always written in the same order?)
>
Only if:
1) The im
> Given that the serialized bytes have to be able to *deserialize* back
> to the original messages, surely if those original messages aren't
> equal, the serialized forms would have to be different too - assuming
> we're talking about the same message type
But, as in my example, that doesn't seem
On Sep 29, 8:22 pm, alopecoid wrote:
> Can serialized messages be used reliably as keys?
>
> In other words, is it guaranteed that...
>
> - Two equal messages will always generate equal byte sequences?
> (Are fields always written in the same order?)
>
> - Two unequal messages will always generat
Hi,
Can serialized messages be used reliably as keys?
In other words, is it guaranteed that...
- Two equal messages will always generate equal byte sequences?
(Are fields always written in the same order?)
- Two unequal messages will always generate unequal byte sequences?
(Are tag identifiers
Well, either system can convert either way (hopefully). The question is in
which format the user prefers to write their schemas -- they should only
have to write one. Personally I'd prefer to write mine in .proto, but I'm
probably biased. :)
On Tue, Sep 29, 2009 at 3:06 AM, sim wrote:
>
> Coo
Bummer.. It would've been a great feature. I'm faced with displaying
several complex nested protos and the simplest way would've been a 2
column list view that was populated by a generic proto reader.
I'm looking at Jon's solution, but I really don't want to have to
implement and maintain 2 prot
In protobuf-net? No. You could deserialize into the expected type and
use reflection, though. It is perhaps something I could consider
should I find time though - presumably in the non-type based branch
(experimental; unstable; incomplete...).
Jon's version may have other options here? dotnet-pro
Is there a way to generically read a protoBuf byte[] and extract a
field tag/name to value mapping?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protob
Hello,
I'm trying to compile protobuf-c and keep getting errors I didn't when
I tried compiling on other machines.
Obviously the preliminary protobuf compilation succeeded. I should
also mention that the previous successful installations were on a 64-
bit machine, where as the current machine I'm
Cool. New syntax I didn't know about! I think this would be useful
for converting the other way around (Proto-to-XML).
On Sep 28, 6:05 pm, Kenton Varda wrote:
> Interesting.
>
> Another way to do this would be to write code based on protobuf reflection
> and custom options, so you could have a
16 matches
Mail list logo
