(1) I basically agree with Jim re the main topic. I don't need to repeat it here, see below. IDL changes may be necessary, but if they can be avoided at all that would be the ideal solution. That should be a main goal, IMHO.
(2) We should move the in/out discussion to some other thread. I think that is a different topic, and yes, I also agree that there have not been that many requests for it so far. OTOH that may not mean much to some extent: provide the tools and people will use it. TL;DR: If someone wants to give it a try, do it. If not, fine. JensG -----Ursprüngliche Nachricht----- From: James E. King III Sent: Wednesday, May 22, 2019 10:54 PM To: jle...@lightblue.com Cc: James E. King III ; dev@thrift.apache.org ; Jens Geyer Subject: Re: THRIFT-66 - Bidirectional communication I think that given the conversation thus far, IDL changes to support bidirectional glue across two transports is not desirable. A superior solution has been designed, one that is firewall-friendly, bidirectional support over a single transport would be a big step forward, and avoid IDL changes entirely. It would make more sense to do that instead. As for in/out/inout, I think the jury is still out (inout?) on that. I'm not sure it's compatible with all languages in all situations. - Jim On Wed, May 22, 2019 at 1:55 AM John Dougrez-Lewis <jle...@lightblue.com> wrote: > > Starting with two channels is a stepping stone on that path. > > Get the IDL extended. > Get the framework working. > Having got it all working, provide an alternate implementation underneath > the IDL using a single channel. > > > -----Original Message----- > From: James E. King III [mailto:jk...@apache.org] > Sent: 21 May 2019 15:17 > To: dev@thrift.apache.org; jle...@lightblue.com > Cc: Jens Geyer > Subject: Re: THRIFT-66 - Bidirectional communication > > I'd prefer to see a solution that implements bidirectional > request/response over a single transport; the in/out stuff hasn't been > requested before (or at least, not much) and I'm still not convinced every > language could support it properly. The nice thing about bidirectional > support is that it could still support older unidirectional clients. The > benefit of a single transport and being able to avoid all the firewall > issues of a double transport far outweighs additional code generation to > glue two transports together. > > On Tue, May 21, 2019 at 1:22 AM John Dougrez-Lewis <jle...@lightblue.com> > wrote: > > > > Indeed, you could just skip the intermediate IDL generation and go > > straight to the language-specific code generation. > > > > The IDL to IDL just serves as a mechanism to localise the necessary > > changes, keeping the existing language-specific code generation code as > > it is, so only the extra plumbing language-specific code needs to > > written. > > > > > > -----Original Message----- > > From: Jens Geyer [mailto:je...@apache.org] > > Sent: 20 May 2019 21:53 > > To: dev@thrift.apache.org > > Subject: Re: THRIFT-66 - Bidirectional communication > > > > Hi, > > > > Sorry, I can't follow. IDL generates language specific code already. > > > > Get me right: Having another IDL to create an IDL to create code from is > > not a bad idea in general (I have done that myself), but I can't see the > > added value in the context of Thrift. I only see things getting way more > > complicated as necessary. > > > > Why can't we model what we want with the great, simple and "to the > > point" > > IDL we have aleady, maybe expand it a bit where suche becomes necessary? > > > > Have fun, > > JensG > > > > > > > > -----Ursprüngliche Nachricht----- > > From: John Dougrez-Lewis > > Sent: Monday, May 20, 2019 7:26 AM > > To: dev@thrift.apache.org > > Subject: RE: THRIFT-66 - Bidirectional communication > > > > > And the benefit would be ... ? > > > > The ability to extend functionality across all languages in a consistent > > way using the existing implementation. > > > > The only additional language-specific code that would need to be added > > would be to plumb-in and glue together the two channels. > > > > > > -----Original Message----- > > From: Jens Geyer [mailto:jensge...@hotmail.com] > > Sent: 19 May 2019 21:01 > > To: dev@thrift.apache.org > > Subject: Re: THRIFT-66 - Bidirectional communication > > > > > > > async was already a keyword long ago. It's now called "oneway". > > > But 'oneway' provides no guaranteed deterministic mechanism of > > > indicating back to the client any > > > > I didn't say that. I just said that async already was used as a keyword. > > > > > > > > What exactly would that preprocessor do? Generate IDL from IDL? > > > Yes. > > > > And the benefit would be ... ? > > > > > > > > -----Ursprüngliche Nachricht----- > > From: John Dougrez-Lewis > > Sent: Saturday, May 18, 2019 8:39 AM > > To: dev@thrift.apache.org > > Subject: RE: THRIFT-66 - Bidirectional communication > > > > Hi, > > > > > At least PUB/SUB can be implemented solely on the transport level. > > > No IDL change necessary. > > > > My understanding is that Thrift generally provides only synchronous > > RPC, making with one synchronous return. How would multiple subsequent > > Subscription updates be sent back to the Client? > > > > > > > async was already a keyword long ago. It's now called "oneway". > > > > But 'oneway' provides no guaranteed deterministic mechanism of > > indicating back to the client any subsequent processing failures of > > the call on the server side, so it appears very fragile and so would > > be difficult to justify it being used in any serious professional > > applications such as Financial Trading Systems. > > > > > > > Not sure if I can follow. What exactly would that preprocessor do? > > > Generate IDL from IDL? > > > > Yes. > > > > > > >> [in/out/inout] parameter > > > > > There was some discussion about this a while ago, don't remember the > > > ticket. > > > Technically that should be possible, since the data are transferred > > > in a struct anyway, so multiple out parameters (or even in/out) > > > should really not be that hard to implement. > > > > Yes, even with just a synchronous IDL extension, out parameters can be > > always be rewritten as members of a struct in the returned values type. > > > > > > ------------------ > > > > In addition, Callback methods could be passed as arguments in the > > A<=>B extended IDL and translated into interface methods on the B=>A > > async response path, e.g. > > > > > > A<=>B IDL: > > > > [aync] methodReturnType Method(arg1, arg2, callbackType Arg) > > > > // define callbackType signature > > > > cbReturnType callbackType(cbArgtype1, cbArgtype2) > > > > =======> > > > > generates: > > > > A=>B IDL > > > > // immediate return to provide handle for context for subsequent async > > return // requires caller to supply callbackHandle to provide context > > for callback > > > > handleType Method(arg1, arg2, callbackHandle) > > > > B=>A IDL > > > > // async return from method call > > void Method(handleType, methodReturnType) > > > > // call for async callback > > cbReturnType CallbackType(handleType, callbackHandle, cbArgtype1, > > cbArgtype2) > > > > > > ----------------- > > > > Regards, > > > > John > > > > > > -----Original Message----- > > From: Jens Geyer [mailto:je...@apache.org] > > Sent: 17 May 2019 23:36 > > To: dev@thrift.apache.org > > Subject: Re: THRIFT-66 - Bidirectional communication > > > > Hi, > > > > > That gets you to the point where Thrift supports and generates > > > bidirectional, async & pub/sub based on IDL > > > > At least PUB/SUB can be implemented solely on the transport level. No > > IDL change necessary. > > > > > > > adding attributes [asyc] method/interface > > > > async was already a keyword long ago. It's now called "oneway". > > > > > > > pre-processing the extended IDL with a new pre-processor to > > > generate the representations of the service definitions for both > > > sides in terms of the current IDL > > > > Not sure if I can follow. What exactly would that preprocessor do? > > Generate IDL from IDL? > > > > As a general statement, I would recommend to strictly separate between > > an interface contract (which the IDL is and should be) and a concrete > > implementation or configuration setup (which the IDL should not be). > > > > > > > [in/out/inout] parameter > > > > There was some discussion about this a while ago, don't remember the > > ticket. > > Technically that should be possible, since the data are transferred in > > a struct anyway, so multiple out parameters (or even in/out) should > > really not be that hard to implement. I have no idea if we run into > > subtle problems with certain languages and how that could be > > circumvented (by using structs > > maybe) and if in/out is really supported by all of them on a language > > level, we will find out. > > > > > > Have fun, > > JensG > > > > > > -----Ursprüngliche Nachricht----- > > From: John Dougrez-Lewis > > Sent: Thursday, May 16, 2019 6:29 AM > > To: 'James E. King III' > > Cc: dev@thrift.apache.org > > Subject: RE: THRIFT-66 - Bidirectional communication > > > > Yes, my suggestion is for an enhancement to Thrift to make it > > bidirectional, as follows: > > > > > > 1) use 2 connections, A => B, and B => A using what is already in place. > > > > 2) write, by hand, a new, supporting choreography code to establish > > this double connection, in the first instance for a single language > > > > 3) extend the IDL support this - adding attributes [asyc] > > method/interface, [pub/sub] method/interface, [in/out/inout] parameter > > > > 4) extend the IDL generation to implement this: > > > > i) pre-processing the extended IDL with a new pre-processor to > > generate the representations of the service definitions for both sides > > in terms of the current IDL > > > > ii) generate the language dependent code required to hook up at > > of the two ends. > > > > 5) implement across multiple languages > > > > > > That gets you to the point where Thrift supports and generates > > bidirectional, async & pub/sub based on IDL > > > > Then, optionally: > > > > 6) Having achieved a working implementation defined by an extended > > IDL, consider re-implementing in terms of a single bidirectional > > transport rather than 2 existing unidirectional independent transports. > > > > > > The extended IDL defining a single async/pubsub A<=>B interface is > > used to generate 2 interfaces: an outgoing A=>B and an async response > > return channel B=>A, e.g.: > > > > > > A<=>B > > [async] returntype functionName (arg1, arg2) => A=>B > > Handletype functionName (arg1, arg2) B=>A > > void functionName (Handletype, returntype) > > > > A<=>B > > [async] returntype functionName (arg1, arg2, [out] arg3) => A=>B > > Handletype functionName (arg1, arg2) B=>A > > void functionName (Handletype, returntype, arg3) > > > > > > A<=>B > > [async] returntype functionName (arg1, arg2, [inout] arg3) => A=>B > > Handletype functionName (arg1, arg2, arg3in) B=>A > > void functionName (Handletype, returntype, arg3out) > > > > > > > > -----Original Message----- > > From: James E. King III [mailto:jk...@apache.org] > > Sent: 15 May 2019 19:02 > > To: jle...@lightblue.com > > Cc: James E. King III; dev@thrift.apache.org > > Subject: Re: THRIFT-66 - Bidirectional communication > > > > Re: Visio - There are no "endpoint" implementations that allow for > > bi-directional communication over a single transport connection today. > > Is that the Visio you were referring to? The only implementation of > > that concept is buried in the THRIFT-66 attachments, and only for C#, > > and it was done on a codebase about 8 years past... > > > > With today's thrift code if you want either end to be a client (make > > requests) or a server (reply to requests) you would need to separately > > instantiate a client or server on each end and have them connect to > > each-other, i.e. > > > > A ---> B (A sends requests to a thrift server on B, B replies, on a > > transport) A <--- B (B sends requests to a thrift server on A, A > > replies, on a transport separate from the last one) > > > > It sounds like what you'd like to get to is: > > > > A <--> B (A and B can function as a client or as a server over the > > same > > transport) > > > > Thrift cannot do the latter today, so I would recommend the former, > > using one transport for each direction. > > > > Given they will both be on the same system, if your languages support > > it, unix domain sockets are quite fast. > > Otherwise if you want a shared memory solution you need to write your > > own transport for that. > > > > - Jim > > > > On Wed, May 15, 2019 at 1:12 PM John Dougrez-Lewis > > <jle...@lightblue.com> > > wrote: > > > > > > Hi Jim, > > > > > > The "oneway" route looks a bit fragile in the face of failures in > > > the subsequent server-side processing which then cannot be signalled > > > back to the client. > > > > > > The 2-way connection would be the way forward for me, particularly > > > since it would work with across multiple languages. > > > > > > My primary use case would be a simple language bridge mechanism for > > > a library to allow processes coded in one language to call, with > > > potentially asynchronously returns, and pub/sub, to another process > > > hosting a library coded in another language running (in the first > > > instance) on the same box, communicating via IPC, preferably fast > > > shared memory, but failing that sockets would do. > > > > > > You put a Visio diagram up back in 2010. Is the underlying source > > > code for that available now ? > > > > > > Rather than hand-rolling the 2-way connection setup/teardown and > > > supporting code, for each and every language each time, it would be > > > nice if Framework code for that could be generated automatically > > > from an enhanced and extended version of the IDL. > > > > > > Regards, > > > > > > John > > > > > > -----Original Message----- > > > From: James E. King III [mailto:jk...@apache.org] > > > Sent: 15 May 2019 12:05 > > > To: dev@thrift.apache.org; jle...@lightblue.com > > > Subject: Re: THRIFT-66 - Bidirectional communication > > > > > > Hello! > > > > > > Thrift is still a dedicated client/server model environment where > > > clients can request and servers reply. The easiest way to make it > > > 2-way today is to open a connection both ways. If you don't have > > > firewalls in the way then you can do this effectively. The more > > > difficult and more correct way to do it would be to rewrite the > > > transport layer to use endpoints in which each side can be a client > > > and/or server for any number of services (using TMultiplexedProtocol > > > on top of another protocol, like TBinaryProtocol). > > > This design allows one end to be a "listener", one end to be an > > > "initiator" (starts the connection), and after they connect they are > > > equal peers with the ability to request or reply of each-other. > > > > > > You can approximate asynchronous behavior by exclusively using > > > "oneway" > > > requests in your design. I'd suggest avoiding use of oneway > > > requests with THttpProtocol varieties however as today there are > > > some issues, since Http transport requires a response to be sent, > > > and "oneway" dictates there is no reply, and most languages do not > > > handle it well right now (there are open backlog issues for this). > > > > > > For a matrix of supported languages, protocols, transports, and > > > server types, see the file LANGUAGES.md at the root of the github > > > repository. > > > > > > Another idea I was toying with a while ago was to add a message bus > > > transport to Thrift which would allow for things like reliable > > > delivery and broadcast semantics but that also does not exist today. > > > > > > - Jim > > > > > > On Wed, May 15, 2019 at 1:05 AM John Dougrez-Lewis > > > <jle...@lightblue.com> > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I was looking for a mechanism to be able to provide > > > > language-agnostic API support to a hobby project I've been working > > > > on for some time. > > > > > > > > > > > > > > > > By following a trail of papers, books and references, I eventually > > > > came across Apache Thrift and have found and started going through > > > > Randy Abernethy's new book. > > > > > > > > > > > > > > > > > > > > > > > > Essentially what I was looking for was support for asynchronous > > > > calls, and by extension, pub/sub and two way communication across > > > > and between multiple languages over some channel, preferably IPC > > > > but in the worst case sockets. > > > > > > > > > > > > > > > > > > > > > > > > Having read the book, I can see that there is support for basic > > > > synchronous RPC between a client and a server over a significant > > > > number of languages and for just a very few languages, such as > > > > java, some element of support for asynchronous callbacks, and > > > > otherwise one-way methods that do not provide indication of > > > > subsequent failure. > > > > > > > > > > > > > > > > It appeared to me one way of extending bi-directional asynchronous > > > > support would be to have the client to set itself up as a server > > > > for the server at the other end to connect to, and then it would > > > > just be a question of choreographing the setting up of a pair of RPC > > > > channels. > > > > > > > > > > > > > > > > An asynchronous call could be implemented by providing a > > > > synchronous method that simply immediately returns a handle to the > > > > caller, and the server would then continue to process the call > > > > request on a background threadpool thread on the server, and the > > > > async result would then be signalled by a call from the server > > > > back to the client on the 2nd channel with the handle providing a > > > > context to lookup the result. > > > > > > > > > > > > > > > > Pub/sub would just then be multiple calls from the server back to > > > > the client. > > > > > > > > > > > > > > > > The whole thing could sit on top of the existing unidirectional > > > > RPC implementation and provide full asynchronous calls & pub/sub > > > > across > > > > *ALL* supported languages at probably very little additional > > > > effort, with no changes to the existing code. > > > > > > > > > > > > > > > > You could then have a framework that extended the existing IDL to > > > > include decoration with attributes for async & pub/sub methods & > > > > in/out parameters. > > > > > > > > > > > > > > > > This extended IDL could then be pre-processed to generate > > > > client-server and server-client service definitions in the > > > > existing base IDL language, together with generating supporting > > > > glue code to compile to provide the support for hooking up the > > > > channels between each side. > > > > > > > > > > > > > > > > I note that THRIFT-66 was raised 10 years ago, but it looks like > > > > the C# code was never made available for release by Dell. > > > > > > > > > > > > > > > > I have some questions: > > > > > > > > > > > > > > > > 1) What is the current state of plans for this supporting this > > > > sort > > > > of > > > > functionality? What issues have been encountered ? > > > > > > > > > > > > > > > > 2) Is there a document/spreadsheet somewhere showing a matrix > > > > of > > > > what > > > > Transports and Protocols are supported for each language? > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
