On 30 June 2017 at 11:22, Keith W <[email protected]> wrote: > Thanks Robbie. > > I'm planning for us to take a look at both the Proton-J change and > Qpid JMS Client next month (I was the original contributor if the Qpid > JMS Client SCRAM SHA module, after all) , so except to see some > patches from us on the reviewboard for comment. I don't think we'll > be able to take on corresponding changes for Proton-C (my C skills are > 17 years rusty), so we'll have to leave those to others. >
I just meant establishing whether any matching changes are actually needed on other bits rather than actually doing them if there are (some tangential discussion suggests it might not be). We'd obviously want to avoid breaking things by only changing some bits at a particular time and not others if they do need it. > For the Proton-J change and Qpid JMS Client releases, we don't need > these changes urgently, so I was hoping to piggyback if there is a > release due in the next four to six weeks, otherwise we might push > things forward ourselves. > I'm happy to spin a release almost any time I'm actually around and not on holiday hehe. If theres demand for something and its considered ready then it can generally be released quickly. > > > On 30 June 2017 at 11:06, Robbie Gemmell <[email protected]> wrote: >> On 29 June 2017 at 13:06, Keith W <[email protected]> wrote: >>> Hello, >>> >>> Are there release dates in mind for Proton-J (0.20.0) and Qpid JMS >>> (0.24.0)? >> >> Nothing specific no, except not next week due to holidays etc (unless >> others feel like doing a release...). Essentially they are mostly >> released whenever theres something interesting enough ready or it >> seems too long otherwise. >> >>> >>> We are moving towards a Qpid Broker J major release next quarter. The >>> release backlog includes QPID-7787 [1] which will utilise the AMQP 1.0 >>> additional data field of the SASL outcome [2]. In order to be useful >>> end to end, this will need a corresponding change in the Qpid JMS >>> Client, QPIDJMS-294 [3], and a Proton J change to expose the data [4]. >>> >> >> Perhaps also including checking the interaction with Dispatch, the c++ >> broker, and proton-c plus bindings when using Cyrus, etc. >> >> I looked at Rob's patch on >> https://issues.apache.org/jira/browse/PROTON-1486 previously and >> mentioned to him it seems like it will work (tests might show :P) >> though I was hesitant whether it would be better to expose the value >> explicitly than feeding it though the same API+fields as the >> challenge/response. I did agree the things that might not work >> shouldnt really happen and are mostly already an issue regardless >> though. >> >> I haven't looked at the client side yet to see whats needed there. >> Perhaps folks that wrote those/related bits might have a better idea? >> :) >> >>> I want to understand the schedule so we can ensure the work on those >>> JIRAs is ready for consideration/inclusion. >>> >>> cheers, Keith. >>> >>> [1] https://issues.apache.org/jira/browse/QPID-7787 >>> [2] >>> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-security-v1.0-os.html#type-sasl-outcome >>> [3] https://issues.apache.org/jira/browse/QPIDJMS-294 >>> [4] https://issues.apache.org/jira/browse/PROTON-1486 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
