thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Duxbury <br...@rapleaf.com>
Subject Re: passing objects by ref
Date Tue, 09 Feb 2010 20:44:35 GMT
I'd be thrilled to see a project that layers on top of Thrift to do what
you're talking about. If you go down that road, definitely let us know.

Personally, my reluctance to add something like that into Thrift natively
stems from my concern about expanding the context of Thrift to a wider
purpose. I think Thrift does a really good job of doing a very specific
thing today, and widening that "thing" to include something as complicated
as network objects could dilute our focus.

That said, if you did come up with a working, multi-language solution that
layers on top of Thrift, I think we'd all be much more amenable to
discussing including something like that.

-Bryan

On Tue, Feb 9, 2010 at 12:34 PM, tomer filiba <tomerfiliba@gmail.com> wrote:

> 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 <bryan@rapleaf.com> 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 <dreiss@facebook.com> 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message