[
https://issues.apache.org/jira/browse/THRIFT-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988546#comment-13988546
]
Bryan Duxbury commented on THRIFT-1239:
---------------------------------------
A scheme is sorta like the "grammar" part of the protocol, whereas TProtocols
are pretty much just how you write out tokens. Binary protocol set the implicit
scheme, and Compact protocol managed to shoehorn into that same scheme by being
stateful.
TupleProtocol needed access to different metadata while encoding and decoding,
though, which necessitated the addition of the Scheme interface.
> 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)
