Hi Folks, I look after the OpenMAMA bridge for Qpid Proton C and we originally built our API based on the pn_messenger interface. However I see that interface is now marked for deprecation, so I'm looking for alternatives. I'd appreciate any feedback on my assessment of the options available which are listed below.
When I look at the alternative options available in https://github.com/apache/qpid-proton/tree/master/examples/c, the options seem to be between: *Messenger:* Deprecated - so let's assume that's going away and not an option *Proactor: *Looks interesting, though no subscription level support and looks to be experimental *Reactor: *I think the proactor pattern looks like a better fit for us due to its asyncronous nature, but this looks to be more stable? (or at least not marked as experimental?) Again, light on subscription integration though. So my initial feeling is to try moving to proactor. My main concern is stability since it looks like it has already made an interface change since 0.17.0 (which expected while it's marked as experimental): https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/c/api/group__proactor.html#ga523ea983380a1566b3b1a7606d66422c. Is this something which is definitely going to be non-experimental soon or is there chance the whole interface could get canned? Which leaves the final question of how to solve the issue with addressing. We have traditionally used one URI per topic to give the subscriber isolation from other data sources (this is market data - large volumes, large number of topics). This has proven very slow so maybe it's going against the grain (it was configurable though in our application). The new API looks like it would encourage more coarse addressing (e.g. maybe one URI per exchange?), then defer to the payload to handle addressing. Does that sound fair or are you supposed to be able to call pn_proactor_connect many times (is it thread safe also)? I'm curious about what sort of addressing patterns that others have used specifically for market data or other use cases with a large number of topics and high volumes? Cheers, Frank
