Hi all - just wanted to get some opinions on $Subject: While I was trying to implement a fix for https://issues.apache.org/jira/browse/PROTON-476 I found that the lifecycle model for the python SASL and SSL objects differs for the C engine. I think the python wrapper's impl is buggy.
In the C engine, these objects are singletons with respect to their associated transport - there can only be one SSL and SASL object associated with a given transport. This is enforce by the C api - the transport provides factory classes for these objects. The python wrapper doesn't enforce this. For both objects, a "public" constructor is supplied (I say "public" because it is exported by the wrapper's __all__ list). This makes it trivial for an application to construct multiple instances of SASL/SSL objects that reference the same underlying C object. While this can technically be done safely using reference counting, I think it may lead to unanticipated behavior - not to mention that it differs from the object model provide by the C engine. I'd like to fix this by modifying the python wrapper to remove the SSL and SASL objects from the __all__ list, and provide factory methods on the Transport class for creating instances of these objects. This would result in a change to the public API. Let me know what you think, thanks, -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
