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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
