[
https://issues.apache.org/jira/browse/THRIFT-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988527#comment-13988527
]
Aleksey Pesternikov commented on THRIFT-1239:
---------------------------------------------
8-[ ]
Can anybody explain why this didn't fit into regular TProtocol implementation
so required inventing IScheme?
To me it screams overengineering.
> TupleProtocol- An extremely compact, temporary protocol
> -------------------------------------------------------
>
> Key: THRIFT-1239
> URL: https://issues.apache.org/jira/browse/THRIFT-1239
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Compiler
> Reporter: Armaan Sarkar
> Assignee: Armaan Sarkar
> Priority: Minor
> Fix For: 0.8
>
> Attachments: pluggable_serializer_master.patch, thrift-1239-v2.patch,
> thrift-1239-v3.patch, thrift-1239-v4.patch, tuple_generator.patch,
> tuple_protocol.patch
>
>
> Currently, protocols are built to be pretty robust to 'schema' changes. This
> is done by sending metadata about when a struct or a field will start/end,
> the number of fields to expect and the types of each field, etc. However,
> there are cases when the recipient knows all of this, even before it receives
> this metadata. In these cases, sending the metadata unnecessarily eats up
> bandwidth. The TupleProtocol rectifies this by sending and receiving only the
> value of each field in a specified order. The only metadata passed is about
> variable information such as the size of a container or which optional fields
> are set.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
