On Mon, 2016-10-31 at 18:26 +0000, Rob Godfrey wrote: > On 31 October 2016 at 17:28, Robbie Gemmell <[email protected] > > > 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: [email protected] For additional commands, e-mail: [email protected]
