On Tue, 2015-03-10 at 11:20 +0000, Gordon Sim wrote: > On 03/10/2015 10:51 AM, Rafael Schloming wrote: > > My tour of the code started with an attempt to figure out what the term > > "sync" was intended to mean since "synchronous" is commonly used to refer > > to both a blocking programming style and a request/response messaging > > pattern, but the two aren't necessarily correlated. (Blocking APIs can do > > asynchronous messaging, and non-blocking APIs can do synchronous > > messaging.) > > Yes, that is a good point. > > (Personally I don't think it necessarily rules out having both under the > same namespace, as long as the detailed semantics are clear. The name > would be a hint for either and indeed both meanings are currently > embodied in the code in that package). > > > As it stands this code could be > > anything from the very early start of a general purpose blocking API for > > proton, to a simple convenience API for one particular scenario. Where it > > falls on this spectrum would significantly influence both its name and > > maturity level. > > Yes, I agree very much with this. The code that is there is at present > both immature and limited. It provides a very simple blocking, > sequential 'adapter' over the reactive core, and additionally a simple > rpc mechanism on top of that. How it evolves is very much open to > feedback from users and other developers.
I think the approach is good, I found it useful for doing RPC. It can probably be generalized and parameterized a bit more. I see an important role for this in providing an on-ramp to proton for developers that are used to "command-style" (I won't say blocking or synchronous) APIs rather than a reactive API (e.g. messenger, messaging) and for simple RPC-like tools (e.g. dispatch's command-line management tools.) Obviously not a replacement for the more powerful reactive API but a useful complement to make proton more approachable to a wider developer audience.
