qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Python wrapper - SASL and SSL class API
Date Wed, 11 Dec 2013 14:58:07 GMT


----- Original Message -----
> From: "Rafael Schloming" <rhs@alum.mit.edu>
> To: proton@qpid.apache.org
> Cc: users@qpid.apache.org
> Sent: Wednesday, December 11, 2013 9:43:59 AM
> Subject: Re: Python wrapper - SASL and SSL class API
> 
> On Wed, Dec 11, 2013 at 9:35 AM, Ken Giusti <kgiusti@redhat.com> wrote:
> 
> >
> > 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.
> >
> 
> Why exactly do you need to change the API to do this? I would expect there
> should be a number of ways to keep it the same, e.g. rename the class and
> use a factory function with the same name as the class, or override __new__
> if you want to keep the class name the same. Am I missing something?
> 

Ah - actually, you've reminding me that there isn't a reason to change the api!  It should
be possible to create a method using the the existing class name, eg:

def SASL(transport):
   return existing SASL associated with transport, or new one if none

and rename the SASL class itself:

class _SASL(object):
.....

Thank you - always helps to have a firm grip on the capabilities of the language you're working
with :)

> --Rafael
> 

-- 
-K

Mime
View raw message