Re: Dynamic Bridge Loading in 2.4.0 and Bridge Backwards Compatibility
I won't make it to today's call, but wanted to give some feedback :
1)I think it is perfectly OK to break backwards compatibility given:
· We are all aware that the API need some architectural improvement, that will yield further benefit down the line. In this case, we would break compatibility to allow introducing change in the future without breaking backward compatibility (bonus point here if you understood what I meant).
· Those non backwards compatibles changes are limited in scope (here just bridges), and here only mw vendors/open source bridge are concerned. The user community doesn't change their application code.
2)My only observation, which is somewhat related, is that we kept the concept of a default payload. I think this break the whole purpose of OpenMama as that means mw bridge must come with their default payload, which is loaded by default, irrespective to the fact you are going to use it or not. I think this is a defect, and was hoping that we will take the occasion of dynamic bridge loading to get this changed. Although it might be a big change as it involves probably deprecating MamaMsg_create in favour of _createForPayload....
I'm very keen to get feedback from the community, and particularly our user community about this.
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Frank Quinn
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.