[ https://issues.apache.org/jira/browse/THRIFT-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15679438#comment-15679438 ]
Jens Geyer commented on THRIFT-3979: ------------------------------------ {quote} To date, thrift has always behaved session-less, i.e. there's no way to correlate information between two API calls and know they are from the same "client". This is quite limiting in terms of interface design. {quote} That's not the case. We store our corelation as a SessionID that the calls carry around. Its just one item of ot too much data and it works like a charm. Correlating calls is (at least) one level above Thrift, and not having it built-in is iby no means limiting. What would really be limiting: If Thrift would force me to use it. With tzhe current design I have all the flexibility in the world. > offer TExtendedBinaryProtocol for customers > ------------------------------------------- > > Key: THRIFT-3979 > URL: https://issues.apache.org/jira/browse/THRIFT-3979 > Project: Thrift > Issue Type: Story > Components: Wish List > Affects Versions: 0.9.3 > Reporter: Xiaoshuang LU > > Sometimes, customers wanna put some options (username, password, id, etc.) in > each request and response. And these options ought to be transparent for > applications. > Unfortunately, thrift protocol does not have good extensibility for extra > functionalities. I would like to propose the following solution to address > this issue. > 1. TMessage adds a new field called "options" > 2. customers set "options" > 3. TExtendedBinaryProtocol writes "options" when "writeMessageBegin" invoked > 4. TExtendedBinaryProtocol reads "options" when "readMessageBegin" invoked -- This message was sent by Atlassian JIRA (v6.3.4#6332)