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.

 

Cheers,

Frank


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


Benjamin Taieb
 

Hi Frank,

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.

 

Cheers,

Ben.

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: 03 February 2016 18:18
To: openmama-dev@...
Subject: [Openmama-dev] Dynamic Bridge Loading in 2.4.0 and Bridge Backwards Compatibility

 

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.

 

Cheers,

Frank


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


Frank Quinn <f.quinn@...>
 

Thanks Ben - glad to see you're happy to take the plunge!

On point #2, I was actually talking to Damian about this very point yesterday and I think I agree with the sentiment of what you're saying, but it's a _little_ off topic as that is related to a customer-facing API change which is a little hairier because it may involve recompiles and possibly code changes on the client side... in saying that, I think there are ways we can alleviate your concerns without needing to change the customer facing interface, so I'll start up a new thread to discuss that.

Cheers,
Frank

On 04/02/16 08:25, Benjamin Taieb wrote:

Hi Frank,

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.

 

Cheers,

Ben.

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: 03 February 2016 18:18
To: openmama-dev@...
Subject: [Openmama-dev] Dynamic Bridge Loading in 2.4.0 and Bridge Backwards Compatibility

 

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.

 

Cheers,

Frank


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



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


Frank Quinn <f.quinn@...>
 

Hi Folks,

On the technical committee call today there was unanimous agreement that this is the right course of action for the 2.4.0 release. However, if anyone else from the community has any objections to this, please let us know and we'll take any feedback on board.

If there are no significant objections, we will consider the issue closed on February 8th, and start actively removing the relevant backwards compatibility components in the code.

Cheers,
Frank

On 03/02/16 18:17, Frank Quinn wrote:

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.

 

Cheers,

Frank



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