[
https://issues.apache.org/jira/browse/THRIFT-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15679438#comment-15679438
]
Jens Geyer edited comment on THRIFT-3979 at 11/19/16 3:37 PM:
--------------------------------------------------------------
{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 correlation as so called SessionID that the
calls carry around. Its just one item of not 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 by 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.
was (Author: jensg):
{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)
