thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diwaker Gupta <diwa...@maginatics.com>
Subject Re: thrift features over protocol buffers
Date Thu, 11 Jul 2013 22:23:31 GMT
I wrote "Thrift vs. Protocol Buffers" just to address such questions:
http://old.floatingsun.net/articles/thrift-vs-protocol-buffers/


On Sat, Jul 6, 2013 at 4:01 PM, Randy Abernethy
<Randy.Abernethy@rx-m.com> wrote:
> Hello S Ahmed,
>
> There are many similarities but also a number of differences between Apache
> Thrift (AT) and Google Protocol Buffers (GPB). Both are great projects and
> in many situations either will solve your problem. Here are some of the
> differences:
>
>  - From a development stand point, AT is a top level open source Apache
> Software Foundation project contributed to by anyone who adds an approved
> patch. GPB is an open source project controlled and maintained by Google.
>
>  - AT supports over 15 programming languages directly. GPB supports
> C++/Java/Python directly, other language implementations are supplied by 3rd
> parties (there are many). In both cases different languages support a
> varying range of features.
>
> - AT and GPB are both IDL based serialization frameworks. Both IDLs support
> the declaration of types and services. AT includes a complete RPC framework
> which allows you to construct RPC clients and servers with a few lines of
> hand written code. GPB generates RPC stubs but does not come with an RPC
> implementation. There are many 3rd party RPC frameworks built around GPB,
> each supporting one or more languages and offering a range of features. Many
> of these 3rd party projects are based on other projects such as Apache MINA
> or Boost.Asio.
>
>  - AT supplies three IDL container types, map, list and set. GPB defines
> repeating groups with a repeated field specification. Both can manage the
> same serialization chores but the container approach operates at a higher
> level of abstraction which may mean fewer lines of user code (e.g a std::map
> or HashMap can be handed directly to AT for serialization).
>
> - GPB encoding and AT Compact Protocol encoding both use varints to reduce
> the size of serialized data on the wire. GPB supports unsigned and fixed
> integers, AT does not, in rare situations this can allow GPB to create a
> smaller wire footprint. GPB can also compact repeated groups of integers a
> bit more efficiently than AT will (with a list, for instance).
>
>  - AT uses a plug in serialization framework with support for JSON, Binary
> and Compact serialization. Binary may be faster than other protocols when
> the platform is CPU bound and not I/O bound. JSON provides web tech interop.
> Custom protocols can also be added to AT easily. GPB has a single integrated
> varint based serialization format.
>
>  - AT supplies a plug in transport layer allowing you to select memory,
> file, network and other end points as serialization targets. AT allows
> transports to be layered, supporting framing, compression and buffering.
> Custom AT transport are easy to build (e.g. adding  support for a messaging
> system or providing an encryption layer). GPB serializes data to/from
> streams. Implementing language oriented steam interfaces allows developers
> to create layers and new end points in GPB solutions. The I/O models are
> similar but GPB leans more on the language stream implementation, where AT
> uses its cross language Transport framework for the same jobs. There are
> pros and cons to both.
>
> There are many other subtle differences but these are the structural ones as
> I see it. Hope this helps.
>
> Regards,
> Randy
>
>
>
> On 7/6/2013 12:53 PM, S Ahmed wrote:
>>
>> How does thrift differ from say google protocol buffers?
>>
>> Other than defining your types in and having the types generated in the
>> various programming languages, how does thrift differ?
>>
>> It seems that thrift also produces the actual service layer that will wrap
>> your service and allow for calls to be made, is this correct?
>>
>
>
> --
> Randy Abernethy
> Managing Partner, RX-M, LLC
> randy.abernethy@rx-m.com
> Cell: +1-415-624-6447
> San Francisco: +1-415-800-2922
> Tokyo: +81-50-5532-8040
> www.rx-m.com
> @rxmllc
>



-- 
http://maginatics.com

Mime
View raw message