I basically agree with Bryan and David here.
Network objects are a higher-level abstraction than the one Thrift implements
(essentially, RPC and data serialization). I'd definitely be supportive of
building this abstraction on top of Thrift, but wouldn't want it to exist at
the base layer, i.e. I don't think network objects should be primitives.
If I were going to implement this I'd probably take a file-descriptor style
approach. There are two ways of doing this that seem reasonable to me and would
be pretty straightforward with an extra IDL layer as you describe.
1) Virtual objects down-compile methods into a set of service functions with a
object-descriptor param:
(within a service)
object NetworkObj {
method doSomethingInt(1:i32 param)
method doSomethingString(1:string hello)
}
Would be down-compiled into:
function NetworkObj_doSomethingInt(-1: i64 obj_descriptor, 1:i32 param)
function NetworkObj_doSomethingString(-1: i64 obj_descriptor, 1:string hello)
2) Or you could implement virtual method-lookup at a higher level, by having
one generic function per network object (this would require another lookup
table)
Down-compile into:
// this would also need special logic to deserialize the appropriate type of
arguments, after doing the method-based dispatch
function NetworkObj_method(-1: i64 obj_descriptor, -2: string method);
-----Original Message-----
From: Bryan Duxbury [mailto:[email protected]]
Sent: Tuesday, February 09, 2010 12:45 PM
To: [email protected]
Subject: Re: passing objects by ref
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 <[email protected]> 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 <[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
> > >
> >
>
