[
https://issues.apache.org/jira/browse/THRIFT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665350#action_12665350
]
Ben Maurer commented on THRIFT-110:
-----------------------------------
Simplifying to just an integer type will require API changes because of this
type of code:
if (ftype == facebook::thrift::protocol::T_I32) {
xfer += iprot->readI32(this->expires);
isset_expires = true;
} else {
( xfer += iprot->skip(ftype);
(}
The change that would be needed is a new method in TProtocol:
TWireField readWireField()
class TWireField {
TWireType type;
short fieldid;
}
enum TWireType {
INTEGER,
STRING,
LIST,
MAP,
STRUCT
}
What this API change means:
1) If you implemented your own TProtocol, you'll need to support somebody
calling any of the readI[8/16/32/64] methods after getting any of the integer
field types.
2) If you generated stubs with the current version of thrift and are using a
current protocol, then you upgrade to a new version of thrift (without
regenerating stubs), your code will not break. TBinaryProtocol will still offer
readField()
3) In order to take advantage of the new protocol, a language binding would
need to change their compiler a bit.
I think this is a small price to pay for a clean file format that offers more
chances for optimization.
> A more compact format
> ----------------------
>
> Key: THRIFT-110
> URL: https://issues.apache.org/jira/browse/THRIFT-110
> Project: Thrift
> Issue Type: Improvement
> Reporter: Noble Paul
> Attachments: compact_proto_spec.txt, compact_proto_spec.txt,
> thrift-110-v2.patch, thrift-110-v3.patch, thrift-110-v4.patch,
> thrift-110-v5.patch, thrift-110.patch
>
>
> Thrift is not very compact in writing out data as (say protobuf) . It does
> not have the concept of variable length integers and various other
> optimizations possible . In Solr we use a lot of such optimizations to make a
> very compact payload. Thrift has a lot common with that format.
> It is all done in a single class
> http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/common/util/NamedListCodec.java?revision=685640&view=markup
> The other optimizations include writing type/value in same byte, very fast
> writes of Strings, externalizable strings etc
> We could use a thrift format for non-java clients and I would like to see it
> as compact as the current java version
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
