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.

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.







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]

Reply via email to