Re: Proton-996: Surfacing SASL mechanisms into Messenger API

[aconway <ac...@redhat.com>]

On Mon, 2015-09-21 at 11:35 -0400, Andrew Stitcher wrote:
> I worked on PROTON-996[1] last week, and added a new C API which
> surfaced the allowed SASL mechanism into the Proton Messenger API.
> 
> For simplicity I added a new API pn_messenger_sasl_allowed_mechs()
> which just mirrored the pn_sasl_allowed_mechs() API.
> 
> However When I went to create a new API for the Python binding (the
> higher level OO binding)It wasn't at all obvious where it fits.
> 
> This is largely because all the transport details were deliberately
> left out of the Messenger API because it is intended to be message
> focused. In practice all the previous transport oriented details were
> specified in the destination address URL.
> 
> So I'm now questioning my whole approach. It could be that the API is
> just, as a whole, inadequate to it's task as it can't cope with all
> the
> complexity necessary. And I think that some would argue that.
> 
> I definitely think that continually adding extra little warts here
> and
> there will make this API unusable in the long term. But even in the
> short term I can't really see how to map this transport detail into
> the
> world of the Python Messenger object.
> 
> Does anyone have any thoughts or advice (ranting and pontificating
> allowed!).
> 


Ohh ranting allowed!

I actually like messenger's idea of a message-oriented API, but I think
it is a mistake to assume you can simply hard code a trivial map of
address-to-connection, or put all the connection details in the URL.
The former is too limited, the latter is no different in practice from
a traditional connection-oriented API, but with extra layers of
abstraction in your way. 

If we really want to push a "connection agnostic" programming model,
then we need to add a separate layer where the application designer can
specify how addresses map to actualy connections, including security
parameters etc.

However I'm not sure that this is the way to go. Qpid dispatch provides
that kind of flexibility *outside* the client/server process where it
is much more, um, flexible. In many/most applications (especially if
you have dispatch router available) your endpoints tend to have just
one or very few connections so abstracting away the connection has
limited value in terms of simplifying the developers problem.