Dynamic Bridge Loading in 2.4.0 and Bridge Backwards Compatibility

Frank Quinn <f.quinn@...>

Hi Folks,


Dynamic Bridge Loading is coming in 2.4.0 and it brings with it a level of flexibility which is new to OpenMAMA’s internal bridges. It effectively allows:


1.       OpenMAMA to have the concept of mandatory bridge functions (thereby failing to load incompatible bridges where these bridge functions are not present).

2.       Creation of new and optional bridge functions will no longer break the bridge interface itself.

3.       Reordering of methods in each bridge will no longer break the bridge.

4.       Third parties may create OpenMAMA bridges without having to reserve enum values with the OpenMAMA project.


Dynamic bridge loading itself was designed with backwards compatibility in mind, but the more we spoke with users in the community, the more we understood that backwards compatibility in the bridge (as opposed to within the OpenMAMA API itself) is nowhere near as important as avoiding run time crashes due to incompatible bridges being loaded. Note that the upcoming Publisher Events framework in its current form actually depends on this functionality as it involves updating of bridge functions.


With that in mind, we would like to propose that the internal bridge interface (again, not to be confused with the OpenMAMA API which will remain unchanged) for OpenMAMA 2.4.x is not backwards compatible with 2.3.x.


The impact of this would be that each bridge vendor will need to make a few small changes to work with OpenMAMA 2.4.x as documented over at https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading. Failure to conform with the new changes will result in OpenMAMA gracefully failing to load the bridge in question at runtime.


Taking this stance now will:


1.       Reduce the amount of code which third party bridge developers need to maintain.

2.       Ensure that we do not get hit with compatibility issues due to third party bridges not populating the bridge in a way which OpenMAMA expects in future.

3.       Allow us to retire a bunch of code rather than have a large conditional revolving around “if this is not a recent bridge”.

4.       Make it much easier for bridge developers to remain compatible with future OpenMAMA bridge changes going forward.


We will be discussing on a technical committee call tomorrow whether or not it’s OK to break backwards compatibility. Depending on the outcome of that, we may be sending around a note to this list offering an opportunity for other members of the community to object before pulling the trigger on this.




The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC

Join Openmama-dev@lists.openmama.org to automatically receive all group messages.