Making a long story short, it seems that Thrift does not offer much
benefit for the current Tashi code base. If at some point it is
necessary to expose a Thrift interface, there are ways to do this
easily, at the expense of added latency.
I included some comments below with some additional details in case
you find them interesting.
My take on Thrift is that it is useful for:
a. parts of the system were you envision / foresee interoperability
with other languages.
b. storing files / state / data in a language independent manner.
Hypothetical example: suppose you want to allow different
implementations of the tashi client, written in different languages.
Here are a few ways of achieving this:
(1) The client/CM protocol remains "private" and not documented.
Instead you provide a "library" implementation that talks this
protocol, exposes a client API and provides bindings for multiple
languages. Then client tools would link / bind to this API.
(2) The CM exposes a 'raw protocol' interface, perhaps text-based or
using XDR, and the protocol is documented somewhere.
(3) The CM exposes a SOAP interface
(4) The CM exposes a Thrift interface
The main advantage of (1) is that you decouple the protocol from the
client API, so you can evolve the protocol definition as needed. The
client library API becomes your contract, and you can probably extend
it, but not change existing methods.
The problem with (1) is that the client library becomes the only
implementation. It does not allow for real 3rd-party implementations,
other than the tools that bind to the libraries. Also, in order to
support multiple languages, then you have to provide the appropriate
bindings and do the SWIG thing.
I'd say, option (2) is a no-no. Yes, it is language independent, but
then it's harder to change the protocol once multiple implementations
exist. And then, implementing each client requires more work,
everything is done from scratch.
Options (3) and (4) have the advantage of being language independent.
There are many client libraries for SOAP, for many languages. Ditto
for Thrift. The downsides are mainly performance issues if that
matters, and having extra-dependencies, which matters in some cases,
for example when the project code base is relatively small and simple.
Now, the thing is that you can always create 'protocol translator
proxies'. For instance, in the example above you could create a
specialized proxy process that runs collocated with the CM. This
proxy could talk Thrift on one side and then the internal client-CM
protocol to talk to the CM.
That's all.
-JC
On Aug 28, 2009, at 3:31 PM, Jim Cipar wrote:
I would agree with removing it from the default build for now.
I only used thrift because that's what we were using for all of the
RPC at the time. I'd rather that we just settle on one RPC to rule
them all, and I will change the code accordingly.
On Aug 28, 2009, at 2:53 PM, Ryan, Michael P wrote:
I think it's okay for the locality server to depend on Thrift at
least until it becomes core functionality (the only thing we use it
for now is generating a list of work for benchmarks). When it
becomes generally useful, we can have a discussion about the merits
of Thrift. Maybe we can just remove it from the default build
stuff ("make default")? Any thoughts, particularly from Jim?
- Michael
-----Original Message-----
From: Michael Stroucken
Sent: Thursday, August 27, 2009 10:43 PM
To: Ryan, Michael P; Julio Lopez
Subject: tashi and thrift
Hi,
I'd like to make a commit of updated documentation and code that
removes
several references on thrift. However, thrift is still imported in
several places, including the locality server. What is your take on
this?
Greetings,
Michael.
