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