[
https://issues.apache.org/jira/browse/THRIFT-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15679430#comment-15679430
]
Jens Geyer edited comment on THRIFT-3979 at 11/19/16 3:32 PM:
--------------------------------------------------------------
WS-Security has a similar concept to send auth headers, which in theory could
be sent with every request. But having the option does not mean that one has to
use it with every call. The creds for subsequent calls could also be a login
token, so no need to send the creds every time.
The doubts that I personally have with these header concepts is on a more
general level. Whatever could be put into a header is either data that should
be part of normal requests, or meta data that Thrift already models with the
API design. So the header only add more complexity, and the value added is (at
least in my opinion) limited and out of the scope of Thrift. But obviously a
lot of people feel a need for them, then so be it.
was (Author: jensg):
WS-Security has a simolar concept to send auth headers, which in theory could
be sent with every request. But having the option does not mean that one has to
use it with every call. The creds for subsequent calls could also be a login
token, so no need to send the creds every time.
The doubts that I personally have with these header concepts is on a more
general level. Whatever could be put into a header is either data that should
be part of normal requests, or meta data that Thrift already models with the
API design. So the header only add more complexity, and the value added is (at
least in my opinion) limited and out of the scope of Thrift. But obviously a
lot of people feel a need for them, then so be it.
> 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)
