[
https://issues.apache.org/jira/browse/THRIFT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623255#action_12623255
]
noble.paul edited comment on THRIFT-110 at 8/19/08 3:14 AM:
------------------------------------------------------------
bq.Should we be discussing creating a new protocol, or enhancing/formalizing
DenseProtocol, or what?
The protocol must be enhanced significantly . we must extract maximum mileage
out of every bit. We have a lot of other tool/libraries from which we can copy.
bq. Are the names really variable, or could you use enumerated "strings" in the
name/value mappings?
They are not enumerated strings. At least we do not treat it that way.
The idea is that the protocol must not dictate how users must use collection
APIs . We must handle all usecases gracefully
was (Author: noble.paul):
bq.Should we be discussing creating a new protocol, or
enhancing/formalizing DenseProtocol, or what?
The protocol must be enhanced significantly . we must extract maximum mileage
out of every bit. We have a lot of other tool/libraries from which we can copy.
If we do not do it now, it will be hard to change later and may hamper adoption
of thrift.
I could not find any links to dense protocol . But thrift does not have to copy
exactly from any protocol. That may lead to compatibility expectations. Thrift
does not have to aim for interoperability
bq. Are the names really variable, or could you use enumerated "strings" in the
name/value mappings?
They are not enumerated strings. At least we do not treat it that way.
The idea is that the protocol must not dictate how users must use collection
APIs . We must handle all usecases gracefully
> A more compact format
> ----------------------
>
> Key: THRIFT-110
> URL: https://issues.apache.org/jira/browse/THRIFT-110
> Project: Thrift
> Issue Type: Improvement
> Reporter: Noble Paul
>
> 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.
