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 events. 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. --Rafael On Fri, Aug 1, 2014 at 5:44 PM, Andrew Stitcher <astitc...@redhat.com> wrote: > 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 > > >
