Re: Proposed SASL changes (API and functional)
- Original Message - From: Gordon Sim g...@redhat.com To: users@qpid.apache.org Cc: pro...@qpid.apache.org Sent: Monday, March 2, 2015 2:30:28 PM Subject: Re: Proposed SASL changes (API and functional) On 02/24/2015 08:48 PM, Andrew Stitcher wrote: In a short while when people have had enough time to absorb the proposal and comment I will post a code review of the actual code changes. As there are substantial API changes I'd like to get this in for 0.9 because we were intending to stabilise the API at this point. To me it seems a bit late in the cycle for 0.9 for changes of this magnitude and I'd prefer to see it included during 0.10 with any accompanying changes to ssl. +1 to that. While I like where these API changes are headed, I don't think we should hold 0.9 up. I'd prefer cutting 0.9 without these changes. Put the API changes on trunk once 0.9 is out and give us some more time to 'kick the tires'. -K - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Proposed SASL changes (API and functional)
On 03/03/2015 01:50 AM, Andrew Stitcher wrote: On Mon, 2015-03-02 at 18:41 +, Gordon Sim wrote: In fact the c++ broker doesn't use an AMQP 1.0 style layer for SSL at all - i.e. it does not recognise the special AMQP 1.0 TLS header sent in the clear prior to TLS handshaking as described in 5.2 of the AMQP spec. The qpid::messaging c++ client doesn't send one either. Both use the 'alternative establishment' as described by 5.2.1 (though for a different reason than the one suggested there). So yet another point of possible interoperability issues. FYI: Currently Proton-C does not support the AMQP 1.0 style SSL header either to send or receive (they are recognised for error message purposes currently) Thanks for the clarification! I was planning to investigate that, since I knew that ssl 'works' between proton-c and qpidd. - this is a piece of work I have scheduled post the SASL integration. We probably want to retain some way of using the 'alternative establishment' as well, in order to not lose interop. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Proposed SASL changes (API and functional)
On Tue, 2015-03-03 at 15:28 +, Gordon Sim wrote: On 03/03/2015 01:50 AM, Andrew Stitcher wrote: On Mon, 2015-03-02 at 18:41 +, Gordon Sim wrote: In fact the c++ broker doesn't use an AMQP 1.0 style layer for SSL at all - i.e. it does not recognise the special AMQP 1.0 TLS header sent in the clear prior to TLS handshaking as described in 5.2 of the AMQP spec. The qpid::messaging c++ client doesn't send one either. Both use the 'alternative establishment' as described by 5.2.1 (though for a different reason than the one suggested there). So yet another point of possible interoperability issues. FYI: Currently Proton-C does not support the AMQP 1.0 style SSL header either to send or receive (they are recognised for error message purposes currently) Thanks for the clarification! I was planning to investigate that, since I knew that ssl 'works' between proton-c and qpidd. - this is a piece of work I have scheduled post the SASL integration. We probably want to retain some way of using the 'alternative establishment' as well, in order to not lose interop. Here my focus is on the server end autodetection, so better interop is achieved by coping with both SSL alternatives. I think that initially, the correct default for the client should be to use the AMQP 1.0 type header for the default port (5672) and the alternative establishment for other ports (5761 or other). Andrew - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Proton reactor send and receive tools
In PROTON-818, Cliff has introduced some examples using the C reactor interfaces. For simple programs, they are pretty long. - reactor-recv.c - http://goo.gl/4QkqsE - 447 lines - reactor-send.c - http://goo.gl/Zcg9Sy - 389 lines Some questions: - The examples carry connections in a context in order to do clean shutdown. Is that something the reactor should be capable of doing? - There's also a little extra logic in these to do clean object deletion. Is there a better way to handle the references to avoid this? - There's some state management for timeouts. Could that go into a standard handler? It seems like it will be a common case. - Can the endpoint setup in these examples go into a standard handler? - The message handling is verbose. It seems attractive to have something akin to the message.send and .recv that we have in Python. Justin
Re: 0.32 release update - Beta is available
OK running broker and c++ messaging client work on windows Visual Studio 2010, x86, debug * Running with today's proton master branch * Runs C++ messaging examples - Original Message - From: Justin Ross justin.r...@gmail.com To: users@qpid.apache.org Sent: Friday, February 20, 2015 6:39:24 AM Subject: 0.32 release update - Beta is available Hi, everyone. We have branched for release, and 0.32 beta is now available. Release branch: https://svn.apache.org/repos/asf/qpid/branches/0.32/ Release artifacts: https://dist.apache.org/repos/dist/dev/qpid/0.32-beta/ Release tool log output: http://people.apache.org/~jross/qpid-0.32-beta.log This is pre-release software, for testing only. Now that we've branched, 0.32 changes require developer review and release manager approval. See the release page for details. It means as well that trunk has opened for forward development. Please test the beta in your environment and report your results on the list. Thank you very much to those who tested the alpha. The next planned build is our first RC on March 4th. Thanks! Justin --- 0.32 release page: https://cwiki.apache.org/confluence/display/qpid/0.32+Release - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
