[
https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642831#action_12642831
]
Bryan Duxbury commented on THRIFT-167:
--------------------------------------
We still need end methods. This is because the structure doing the
serialization runs the serialization, not the protocol. If the protocol was in
charge, then this would make sense. It'd also make sense if we made
Thrift-specific collection subclasses that knew how to serialize themselves.
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Attachments: thrift-167.patch
>
>
> In doing some exploratory coding on THRIFT-110, it's clear that some
> improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the
> TField and value simultaneously. For instance, we'd have writeString(str) and
> writeStringField(field, str). This way, the protocol would know explicitly
> that it can write the field id, type header, and value all at once. The
> exsiting overload (writeString(str)) would still be used when writing
> containers' contents.
> Existing protocols can implement this behavior very simply as a call to
> writeField then writeString, so we wouldn't have to do a ton of work to
> recode them completely. Code generators would have to change to take full
> advantage of this new interface, but existing generated code would still
> work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
