I also would not like to see Thrift go this direction. That's not to say that you can't still use Thrift to get a good RPC interface, though. For one thing, you could reformulate your API to be method based instead of object based. Another approach would be to return objects, but keep all the methods on a single service interface where the methods take the object that should be the receiver as the first argument. However, this approach could get clunky.
Finally, you could use a method based Thrift RPC that you wrap with your own client-side "object" libraries. This would let you worry about your users' interface and forget about all the networky stuff. -Bryan On Tue, Feb 9, 2010 at 9:33 AM, David Reiss <[email protected]> wrote: > > so my question is -- is this a planned feature? > No. > > > a desired feature? > Not by me. > > > if our company is willing to implement such a feature (at least for java > and > > csharp), will it be welcomed? > I can't speak for everyone, but I don't think this kind of model belongs in > Thrift. Network objects are complicated, exposing a variety of distributed > programming problems like A passing a handle to B that then passes it to C. > I think it is best to keep Thrift an easy-to-understand RPC mechanism and > let more complex abstractions be built on top of it. > > --David >
