thrift features over protocol buffers

[S Ahmed <sa...@gmail.com>]

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?

Re: thrift features over protocol buffers

[Diwaker Gupta <di...@maginatics.com>]

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
<Ra...@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

Re: thrift features over protocol buffers

[Randy Abernethy <Ra...@rx-m.com>]

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