well, client-side libraries are not an option for us, because it means maintaining too many codebases, and converting the entire project to method-oriented instead of object-oriented is not doable either. perhaps thrift then is not for us, and we'd have to resort to an in-house solution.
on the other hand, i just thought about it, so it's quite raw, but we can utilize thrift as a low-level RPC: we could define a more powerful IDL than what thrift uses, that could express passing objects by-ref, etc., and write a rather simple compiler to generate thrift IDLs and the extra "binding code" required for each language. this way, we have a rather small per-language codebase to maintain, and thrift would do most of the "dirty work" (handling transport, serialization, etc.) for us. i'll have to look deeper into it, but on the surface it seems doable. and since it's a layer on top of thrift, we'd be mostly agnostic to new releases (except for interface breakage). frankly, i don't see what your reasons against such a feature are... i'm sure many projects would be happy to use it. since thrift is labeled "0.2.0", i thought there's still plenty of room for experimentation and new features... by the way, is there any roadmap for planned features? anyway, perhaps you'd be willing to reconsider "by-ref objects" later on. thanks, -tomer An NCO and a Gentleman On Tue, Feb 9, 2010 at 20:31, Bryan Duxbury <[email protected]> wrote: > 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 > > >
