Hi Folks,

I've got a broker based Qpid Proton implementation here that I have been knocking together in my spare time. It needs a little bit of tidy up before I submit it, but it seems to work at the moment complete with configurable URI paths based on the MAMA source / symbol. For example:

# Source which you are going to consume from
# %r : Root (only for market data subscriptions, otherwise blank). e.g. _MD
# %S : MAMA Source / Symbol Namespace. e.g. OPENMAMA
# %s : Symbol / Topic. e.g. MSFT
# %u : uuid. e.g. 4542dc20-f1ae-11e3-ac10-0800200c9a66
# This is where we send subscription requests and requests for request / reply
mama.qpid.transport.qpidbroker.type=broker
mama.qpid.transport.qpidbroker.outgoing_url=topic://127.0.0.1/MAMA/%r/%S/%s
# This is where we listen for incoming messages
mama.qpid.transport.qpidbroker.incoming_url=topic://127.0.0.1/MAMA/%r/%S/%s
# This is where we listen for replies during request / reply
mama.qpid.transport.qpidbroker.reply_url=topic://127.0.0.1/MAMA/%u

Note that as part of this change, I noticed some general inconsistencies with what various MAMA applications and APIs provide to the bridge in terms of roots, namespaces (sources) and topics (e.g. the DQ Publisher collapses all of the above into a single topic assuming the bridge can cope with this, but MAMA market data subscriptions split everything up). With this in mind, I made the bridge handle these nuances in a much more centralized way, but in the process, I have also broken backwards compatibility.

Considering the fact that Phil's patch [PATCH] QPID: Moving meta info to application properties also breaks backwards compatibility, I think we should take this opportunity to either resurrect the feature-qpid-bridge feature branch or else create a new one specifically for these changes (that is, changes which are necessary, but will break backwards compatibility) so that we can group them together as part of a single upcoming MAMA qpid proton bridge 1.1 release with full broker support if that sounds reasonable? It would give us something to work off without constantly breaking backwards compatibility on the next branch which I'm sure a lot of people are developing off.

Also, I would welcome any volunteers for testing the broker based implementation when it's up on git (wherever that may be)...

Cheers,
Frank