Re: inconsistent proton library names?

2013-01-07 Thread Rob Godfrey
I've not looked at the branch lately (only just back from vacation), but I would very much hope that there would be nothing preventing having both the JNI and native-Java libraries in the classpath, and allowing for explicit creation of the desired implementation of Connection / Messenger /

Re: inconsistent proton library names?

2013-01-07 Thread Phil Harvey
Hi Rob, I believe we're thinking along the same lines. The ServiceLoader approach does indeed only affect which implementation you get by default. We will also allow the client to explicitly choose their implementation if they wish, and there will be no problem with both implmentations being

Re: Updating versions (was: 0.3 RC1)

2013-01-07 Thread Darryl L. Pierce
On Fri, Jan 04, 2013 at 03:56:54PM -0500, Rafael Schloming wrote: Not difficult, no. We just have to pass it through a similar filter as would be done when using autoconf. For development purposes the version doesn't matter, just when we're creating those artifacts. So we could change

Re: inconsistent proton library names?

2013-01-07 Thread Darryl L. Pierce
On Fri, Jan 04, 2013 at 03:49:57PM -0500, Rafael Schloming wrote: Compared to the other bindings, it seems inconsistent for the former to state its Perl-ness in its name, and for the latter to state its Swig-ness. Thoughts? Negative on Perl. The raw Perl extension is named

[jira] [Resolved] (PROTON-171) after connection close, proton-c SSL decryption fails when left-over bytes passed to input()

2013-01-07 Thread Ken Giusti (JIRA)
[ https://issues.apache.org/jira/browse/PROTON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-171. --- Resolution: Fixed Fix Version/s: 0.3