+1 to Alan's comments.
> -----Original Message-----
> From: Alan Conway [mailto:acon...@redhat.com]
> Sent: Monday, October 31, 2016 2:51 PM
> To: users@qpid.apache.org
> Subject: Re: Proton's road ahead
>
> On Mon, 2016-10-31 at 18:26 +0000, Rob Godfrey wrote:
> > On 31 October 2016 at 17:28, Robbie Gemmell
> <robbie.gemm...@gmail.com
> > >
> > wrote:
> >
> > > > I was going to bring up a similar question - do we believe we are
> > > actually
> > > >
> > > > getting benefit from trying to keep the API of Proton-J and
> > > > Proton-C "identical"? It's been a while since I worked on it, but
> > > > my feelings at the time were that the enforcing of API identity
> > > > (rather than
> > > equivalence)
> > > >
> > > > actually made proton-j much less natural to use and not
> > > > insignificantly more difficult to maintain. I'd certainly like to
> > > > see something with functional equivalence between C and Java, but
> > > > it seems like we've
> > > actually
> > > >
> > > > fallen far behind on that with the lack of a reactive api.
> > > >
> > >
> > > No, I don't think keeping API 'identical' has given benefit to
> > > warrant some of the less natural cases. That said, I'm not sure its
> > > actually tried as much as it was in the past either, since they have
> > > actually diverged in API in cases already, e.g. SASL handling is
> > > entirely different between them these days (though partly because
> > > proton-c changed and proton-j did not).
> > >
> >
> > :-) Yeah - that was my impression too... My intent here was really to
> > see if we can better restate the goals of Proton-J in particular so
> > that we focus on an equivalence and maybe at the same time then look
> > to keep the two libraries closer in functionality (i.e. not leaving
> > the Java libraries behind because it is a pain in the ass to try to
> > write C code in
> > Java)
>
> +1. Interop is the most important issue. Keeping things similar to
> lower learning curves is a good thing, but forcing one language into the mold
> of another raises the learning curve, so there's a balance to be struck. I
> think
> "native X programmer can walk up and use the X binding" should weigh a
> little more than "programmer who used Y binding can immediately use the X
> binding". Both of those are far more important than "it lets us re-use
> automated tests in Python and gloss over writing tests in the binding
> languages."
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org
