I'm not a longtime user or developer of Thrift, but I've worked with a
lot of RPC systems in the past, and have implemented a CORBA ORB in a
product.
When Thrift came out, I saw two excellent things in it:
(1) explicit support and facilitation for versioning, both of
interfaces and of the framework itself. But esp. of interfaces.
(2) A decision to avoid "local/remote transparency". This shows up in
lots of ways, but one way is that the only data-structures that are
supported are trees. No DAGs, no graphs.
Having implemented an ORB, I can attest to the difficulties of
supporting these things in an RPC system. Specifically, you have to
figure out where DAGness can occur, and use hashtables to keep track
of pointers at those spots. It's a pain, and furthermore, it's
inefficient.
I think the Thrift decision to privilege "flat data" was a good one.
Sure, it isn't ideal for all purposes, but it's better to force
applications that need more, to code it themselves, and keep things
simple and fast for the bulk of apps.
At least, that's my 2c.
--chet--
On Saturday, April 13, 2013 02:22:07 PM Jens Geyer wrote:
> Hi *,
>
> I know, I read it somewhere but I couldn't find it again, neither in the
> code, the whitepaper nor in the Wiki. But somewhere there is a remark or
> comment about why recursive types are not supported in Thrift. However, we
> frequently run into a situation where we experience the need for such
> structures, e.g. with hierarchical data:
>
> struct treenode
> {
> 1: string name
> 2: list<treenode> childs
> }
>
> Similarly, one could not do things like the following with Thrift:
>
> struct foo
> {
> 1: bar somefield
> }
>
> struct bar
> {
> 1: foo anotherfield
> }
>
> I would really like to see Thrift enhanced here. Especially transporting
> hierachical data through a Thrift-based API causes a lot of extra headaches.
> So here are my questions:
>
> (1) Could anyone provide a pointer to the comment or remark I mentioned
> above?
>
> (2) What could prevent us from enhancing the IDL this way? Particularly, do
> you see any obious (or not-so-obvious) major problems here with the parser
> and the generators?
>
> (3) Do all supported languages allow such constructs?
>
>
> Thanks in advance for any input you might have,
> JensG
