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 <[email protected]> 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
