incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "scott comer (sccomer)" <>
Subject Re: [PROPOSAL] Etch
Date Fri, 01 Aug 2008 15:15:38 GMT
thrift had a number of issues as we considered it more than a year ago. we thought, well, we
could fix these issues, but as they'd require interface changes then we'd be breaking someone
else's code and the fixes would be substantial and then we'd have to negotiate each and every
one of them, blah, blah. in the end, it was all too much.

i actually had a fully functional basic etch framework put together (hand built code) when
i first checked out thrift (eh, march 2007?). etch was was good enough to be able to compare
the two. the comparison was favorable enough to our path (i.e., near parity in performance,
way better features) we decided to continue our path rather than suffer thrift negatives.

1) the thrift language is not pretty (i16 instead of short, weird numbering of parameters).
2) thrift compiler is written in c. not easy to bring up.
3) no c# binding.
4) while there is some transport independence, the transport is chosen at compile time. there
is no runtime choice for the customer.
5) generated code is not truly transport independent. (e.g., you could not write a generic
soap <-> thrift gateway). generated code deals with stream semantics directly, not an
abstract idea of message which gives etch a lot of its power and simplicity.
6) the type system doesn't always allow for optional arguments (integer value cannot be passed
as null).
7) thrift is not thread safe (or it didn't appear so to me).
8) no extends of structures and exceptions.
9) thrift exceptions are strange.
10) no callbacks.
11) no timeouts.
12) no constants.
13) no object.
14) no enums.
15) no formal comments.
16) no mixin or include.
17) no module.
18) overall interface and implementation flavor is of c++ code ported to java.

thrift does not version services (not in the corba sense). etch doesn't either. they are both
alike in that respect.

a common approach to versioning is that you generate a signature for each method or the entire
service, and two endpoints will only talk to each other if the signature matches (either method
by method or the entire service). this is wrong at either level, as it means you have no upgrade
path which doesn't require complete and perfect redeployment of all clients. corba and onc/rpc
and dce/rpc fall into this category (as well as languages like c/c++/java/c#). i don't think
that soap / web services / xml rpc fall into this model, either.

the thrift/etch/xml model, ignoring small details, are like the original rpc model that cuae
was based on: code your method call into what is (more or less) a hashtable, with field/value
pairs and then a type code (for the operation). then move that over the transport. the receiver
picks and chooses what it wants out of the hashtable. if you send a message type the recipient
doesn't expect, he ignores it. if you send a field the recipient doesn't expect, he ignores
it. if you don't send a field the recipient expects, he can 1) complain, 2) pass on the fact
that it was missing, 3) set it to a default value, 4) crash.

thrift does both 2 and 3. passes a default value and also marks it as not being set. smart
code must check for the presence of a parameter before assuming it is there.

etch does 2, by using reference parameters for native types (such as Integer for int in java,
int? for int in csharp), which makes it both simpler and clearer, and more robust. this comes
with no particular penalty for most of the interesting languages (java, c#, ruby, python,
php, javascript, cuae). the only binding that suffers is c/c++, which is already suffering
plenty for other reasons (threads, storage management, type systems).

scott out

Yonik Seeley wrote:
> On Thu, Jul 31, 2008 at 12:16 PM, James Dixson <> wrote:
>> This a proposal to enter Etch in to the incubator.
> James, could you perhaps describe how this differs from Thrift?
> -Yonik
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message