You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Xiaoshuang LU (JIRA)" <ji...@apache.org> on 2016/11/18 06:50:58 UTC

[jira] [Updated] (THRIFT-3979) offer TExtendedBinaryProtocol for customers

     [ https://issues.apache.org/jira/browse/THRIFT-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Xiaoshuang LU updated THRIFT-3979:
----------------------------------
    Description: 
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

  was:
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


> 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)