>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
