thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Evaluation of thrift
Date Thu, 19 Feb 2009 03:01:56 GMT
I think that you have this exactly backwards.

Thrift is intended for very large applications involving many services
running on even more machines.

Atomic upgrades are just not possible in such an environment.  It is
therefore critical to provide for ways for old/new clients to interact with
old/new services.  Thrift actually does this extremely well and provides
some really good methods for doing rolling upgrades in a fairly seamless
manner.

I agree that it is usually good for services to lead clients in terms of
upgrades so that you only have to deal with backward compatibility on the
service side rather than on both sides, but handling all four cases in the
cross product of (old + new client) x (old + new service) is sometimes
really important.  Thrift allows this.  Systems with more intricate service
contracts generally make this *really* hard.

On Wed, Feb 18, 2009 at 6:06 AM, Zhan Xu <zhan.xu@gmail.com> wrote:

> 6. Versioning   How is the versioning of services handled?  Can old
> clients interact with new service definitions?  Can new clients
> interact with older service definitions?
> A: Versioning is provided by defining field version number. However,
> it does not provide versioning of the service contract. Old clients
> can interact with new service. It's dangerous for new clients to
> interact with old service.
>



-- 
Ted Dunning, CTO
DeepDyve

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message