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 
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 
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 

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 
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.

Reply via email to