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

Reply via email to