[
https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639487#action_12639487
]
Bryan Duxbury commented on THRIFT-167:
--------------------------------------
The deserialization code doesn't look any different at all. The serialization
code might look like:
{code}
writeStringField(new TField(1, TType.STRING), my_str_field);
writeI32Field(new TField(2, TType.I32), my_i32_field);
writeListField(new TList(TType.I32, my_list_field.size()));
for (int i = 0; i < my_list_field.size(); i++) {
writeI32(my_list_field.get(i));
}
{code}
I have a patch I will post later today that's a little more descriptive
> 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
>
> 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.
