Re: New SASL capability for the Python client
On Wed, 2009-11-11 at 15:50 -0500, Ted Ross wrote: Full SASL authentication/encryption capability for the Python client was added to the trunk at revision 834975. A new Python module qpidsasl implemented in C++ and wrapped for Python using Swig was introduced. This wrapper provides a generalized binding to the Cyrus SASL library. The Python client tries to import this module. If it cannot find it, it will revert to built-in capability that only provides ANONYMOUS and PLAIN authentication mechanisms. This would appear to not really be connected with qpid itself, but rather be a (very) useful addition to the python (and ruby) libraries. I'd say it would actually be better and more generally useful (for other applications) to put this code in an entirely separate repository from qpid and for it to distributed entirely separately from qpid. And so to remove the qpid element of its name. For Fedora (and the like you'd package it in packages called python-sasl, ruby-sasl unless those names are already taken) Have I missed something here that makes this actually specific to qpid? Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: New SASL capability for the Python client
On Wed, 2009-11-11 at 16:29 -0500, Andrew Stitcher wrote: On Wed, 2009-11-11 at 15:50 -0500, Ted Ross wrote: Full SASL authentication/encryption capability for the Python client was added to the trunk at revision 834975. A new Python module qpidsasl implemented in C++ and wrapped for Python using Swig was introduced. This wrapper provides a generalized binding to the Cyrus SASL library. The Python client tries to import this module. If it cannot find it, it will revert to built-in capability that only provides ANONYMOUS and PLAIN authentication mechanisms. This would appear to not really be connected with qpid itself, but rather be a (very) useful addition to the python (and ruby) libraries. I'd say it would actually be better and more generally useful (for other applications) to put this code in an entirely separate repository from qpid and for it to distributed entirely separately from qpid. And so to remove the qpid element of its name. Specifically I'd add that its location in the source tree is not correct in my mind - it is not really any part of the c++ implementation of the amqp protocol and it is not a binding to a any qpid library so putting it in cpp/bindings is more confusing than not. It also adds to an already complex c++ build. I'd prefer to see it moved to its own top level directory until we can put it outside qpid altogether. Say in sasl. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: New SASL capability for the Python client
Andrew Stitcher wrote: On Wed, 2009-11-11 at 16:29 -0500, Andrew Stitcher wrote: On Wed, 2009-11-11 at 15:50 -0500, Ted Ross wrote: Full SASL authentication/encryption capability for the Python client was added to the trunk at revision 834975. A new Python module qpidsasl implemented in C++ and wrapped for Python using Swig was introduced. This wrapper provides a generalized binding to the Cyrus SASL library. The Python client tries to import this module. If it cannot find it, it will revert to built-in capability that only provides ANONYMOUS and PLAIN authentication mechanisms. This would appear to not really be connected with qpid itself, but rather be a (very) useful addition to the python (and ruby) libraries. I'd say it would actually be better and more generally useful (for other applications) to put this code in an entirely separate repository from qpid and for it to distributed entirely separately from qpid. And so to remove the qpid element of its name. Specifically I'd add that its location in the source tree is not correct in my mind - it is not really any part of the c++ implementation of the amqp protocol and it is not a binding to a any qpid library so putting it in cpp/bindings is more confusing than not. It also adds to an already complex c++ build. I'd prefer to see it moved to its own top level directory until we can put it outside qpid altogether. Say in sasl. maybe create a util/sasl directory... I would not go to the effort of another package unless there is a LOT of interest to do so Carl.
Re: New SASL capability for the Python client
On 11/11/2009 04:29 PM, Andrew Stitcher wrote: On Wed, 2009-11-11 at 15:50 -0500, Ted Ross wrote: Full SASL authentication/encryption capability for the Python client was added to the trunk at revision 834975. A new Python module qpidsasl implemented in C++ and wrapped for Python using Swig was introduced. This wrapper provides a generalized binding to the Cyrus SASL library. The Python client tries to import this module. If it cannot find it, it will revert to built-in capability that only provides ANONYMOUS and PLAIN authentication mechanisms. This would appear to not really be connected with qpid itself, but rather be a (very) useful addition to the python (and ruby) libraries. I'd say it would actually be better and more generally useful (for other applications) to put this code in an entirely separate repository from qpid and for it to distributed entirely separately from qpid. And so to remove the qpid element of its name. For Fedora (and the like you'd package it in packages called python-sasl, ruby-sasl unless those names are already taken) Have I missed something here that makes this actually specific to qpid? Andrew The library that holds the wrapper code is libsaslwrapper.so. The Python binding I called qpidsasl but you are correct in saying that there is nothing qpid or messaging related in either the library or the module. All the library does is provide an alternate API that doesn't rely on callbacks and is easily wrapped in scripting languages. I'd be happy to move the whole thing to a top level directory under qpid if there's a consensus that that is the right thing to do. I assume that we, as the Qpid community, don't have access to directories above qpid. I just wanted to implement SASL for Python and Ruby, not start a whole new project. -Ted - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
