Clearly the protocols and the modification types need to be in sync,
but saying that a certain number of bits should be reserved is too
specific. How would that map to the JSON protocol, for instance?
It seems like we've arrived at some consensus. Should we create a new
issue for making type modifiers and get to work?
-Bryan
On Aug 21, 2008, at 5:17 PM, Chad Walters wrote:
I'm fine with suggesting we keep the list short, but isn't saying we
keep 2 bits free an implementation concern for protocols?
It is and it isn't. I think its reasonable for the framework to
concern itself with how the protocols might implement the
requirements that the framework is imposing. If we have more than
256 possible modified types, then it becomes impossible for any
protocol to represent a type and its modifiers in a single byte.
I presume this would mean that the default modifier should be
interpreted as "variable", and that protocols can feel free to
compress all ints by default.
Yes, that was the intent of the scheme I was proposing.
Chad
On 8/21/08 5:06 PM, "Bryan Duxbury" <[EMAIL PROTECTED]> wrote:
Comments inline.
On Aug 21, 2008, at 4:57 PM, Chad Walters wrote:
Looking at things from the standpoint of efficiency also argues for
a limited set of modifiers, since we need to actually pass this
information on the wire.
In THRIFT-110, I suggest that we reserve 2 bits at the top of the
type byte for modifiers. This allows for 3 different modifiers for
any given primary type (plus a default).
I'm fine with suggesting we keep the list short, but isn't saying we
keep 2 bits free an implementation concern for protocols?
For integer types, I suggested that we add "fixed" and
"zipper"/"zigzag". The default assumption would be that a variable
encoding could be used. "fixed" would mean that variable encoding
is unlikely to be helpful, and "zipper"/"zigzag" would suggest a
variable encoding suitable for fields likely to contain a mix of
negative and positive values.
I presume this would mean that the default modifier should be
interpreted as "variable", and that protocols can feel free to
compress all ints by default.
For string types, I suggested that we add "extern". Strings marked
with this modifier could be stored in some separate indexed table
and referenced by index when passed through the protocol.
Does this sound like a good starting point? Are there other
modifiers we'd like to add?
Chad
