[
https://issues.apache.org/jira/browse/THRIFT-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15676702#comment-15676702
]
Xiaoshuang LU commented on THRIFT-3979:
---------------------------------------
Hi [~jensg], thanks for your information. I appreciate it.
I have some questions about the Header things.
1. Shall we keep the compability between this Header and old protocols. e.g.
what is the expected behavior if one side uses Header while the other uses old
protocol (assuming TBinaryProtocol)?
2. Appears that TFramedTransport is redundant since the leading 4 bytes or 12
bytes of Header describe the size of following Protocol Data Unit.
> offer TExtendedBinaryProtocol for customers
> -------------------------------------------
>
> Key: THRIFT-3979
> URL: https://issues.apache.org/jira/browse/THRIFT-3979
> Project: Thrift
> Issue Type: Story
> Components: C++ - Library, Java - Library
> 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)
