I did think about the possibility of doing this initially, however the
notion of having a transport bound to a connection where each have two
distinct collectors struck me as kind of odd/problematic. I don't know that
it's a meaningful thing to do since you would lose ordering between events
generated by the transport and events generated by the connection. That
might be ok, but I didn't want to think too hard about it at the time so I
decided to simplify by having the transport simply inherit the connection's
collector. I also didn't want to add unnecessary boilerplate by having
extra configurability that (almost) always needs to be set up the same way.

Really the purpose of having the transport decoupled from the connection is
to allow the user to step through the header exchange and sasl negotiation
and have a peek at the open frame prior to constructing/configuring a
connection, e.g. an implementation may want to construct/configure the
connection differently depending on which hostname is specified in the open
frame. Beyond allowing a peek at the open frame though, the transport
really can't process any frames without being bound to a connection, so I
wouldn't say the lifecycle of the transport is *entirely* decoupled from
the connection. At the moment in the context of events its fairly useless
to use an unbound transport given that the sasl layer doesn't generate any

Given all this I'd suggest keeping PROTON-635 simple and addressing your
question in the context of the larger issue of how to make the sasl layer
properly event-enabled. I think for the latter issue we probably need to
extend one of the examples/demos to do something more sophisticated with
sasl and maybe do vhosts or something in order to motivate separating the
connection creation/config from transport. I think those scenarios should
probably drive any API changes. I agree you'd probably want to get events
prior to having a connection in those scenarios, however I really don't
want to end up with the connection, transport, and sasl layer all
potentially having independent collectors that always need to be set to the
same thing in order to be used sanely.


On Fri, Aug 1, 2014 at 5:44 PM, Andrew Stitcher <astitc...@redhat.com>

> I've been looking at fixing PROTON-635 (Not enough PN_TRANSPORT events
> being generated for a driver).
> It occurs to me that since the lifecycle of pn_transport_t and
> pn_connection_t objects are completely independent it makes sense (to me
> at least) that PN_TRANSPORT events get sent to a transport collector
> rather than a connection collector.
> This would solve the problem that you can't sent transport events if the
> transport is not associated with a connections.
> Obviously if you want to receive all the events on the same collector
> then you can associate the same collector to the transport and the
> connection.
> Thoughts? Agreement? Obvious flaws (not such obvious flaws) with this
> idea?
> Thanks
> Andrew

Reply via email to