Hey there,
This might a stupid question, but i haven't found anything certain in the
docs/specs about that:
Our main goal is actually to keep compatibility while syncing a tree.
The protocol is actually just one giant oneof containing all possible paths
for the tree:
message TreeNodeChanged {
oneof key {
sometype path_to_node1 = 1;
sometype path_to_node2 = 2;
...
}
}
and thats already working.
The problem is however that we don't only want forward backward compability
between server and client, but also sideways:
e.g. person A introduced message index 2 and also did person B, both
meaning totally different things, but it should be recognized and
ignored(/or maybe even accepted?! if we find a way to do this)
So the idea of my mate was to make the field number a hash of the
path_to_node!
Candidates are e.g. a 32bit FNV-hash or maybe an adapted CRC32. This would
both mean field numbers in a pretty high area.
Maybe we're going the totally wrong way here but following this path leads
to the following issues:
1) what is the maximum value of the protobuf field numbers?
In the proto language specification
<https://developers.google.com/protocol-buffers/docs/reference/proto3-spec#fields>
it simply says its of type "intLit" and intLit is:
intLit = decimalLit | octalLit | hexLit
> decimalLit = ( "1" … "9" ) { decimalDigit }
> octalLit = "0" { octalDigit }
> hexLit = "0" ( "x" | "X" ) hexDigit { hexDigit }
>
>
So this means only decimal and hexadecimal values are actually allowed
doesnt it?
Then however given:
decimalDigit = "0" … "9"
hexDigit = "0" … "9" | "A" … "F" | "a" … "f"
Means it has different limits for hex and int notation, is that correct?
I mean:
the max value for decimalLit is one billion-1 : "999 999 999"
according to this specs, which fits fine in a 32bit integer (with 30bits
set)
but for base 16 its allowed length is 16! which would be awesome cause that
would mean an allowed integer size of 64bit.
So which one is true? Both?
which leads to issue 2:
1) are there issues with high field numbers
And are they even tested at all?
I've red elsewhere
<https://developers.google.com/protocol-buffers/docs/proto#customoptions>
that *"we have used field numbers in the range 50000-99999. This range is
reserved for internal use within individual organizations"*
which would suggest that even values above 50 000 are uncommen ..
Furthermore some people mentioned high values would suffer from beeing less
performant, but: in how far is that relevant? Only because the index number
consumes slightly more memory?
Well: Maybe we totally ask the wrong questions here and theres a much
simpler logic already introduced or invented to better make protobuf
message version independent, if yes we would be happy to hear them!
Thanks in advance and for reading all this stuff :)
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
