Adding new bridges


Tom Doust
 

I just want to throw some thoughts into the air here about simplifying the process of adding new bridges.

 

As things stand, with OM 2.1.1.2,  if I want to run a new middleware bridge I have to add a value to the enum mamaMiddleware

in middleware.h and a case to the switch statement in middleware.c, effectively forcing a new release of OM if anyone else wants to work with the new bridge

 

Further, I’m constrained to the name of my shared lib though the code in mama_loadBridgeWithPathInternal and the stuff in platform.c - openSharedLib

that builds the library name. From a development perspective this makes is difficult to run multiple variants.

 

I don’t see any problem with moving the work that is done by the enum/switch on the middleware name to an external config and also passing the library name as an optional parameter somewhere, again, possibly read from external config.

 

There may be some good reasons for things being the way they are, so I’m interested in any feedback, comments etc, before we (Tick42) consider contributing some enhancements in this area.

 

 

 

TOM DOUST | Head of Consultancy                                                                                                         


TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@... | http://www.tick42.com  


 

 


mschonberg <mschonberg@...>
 

On Wed, 25 Jul 2012, Tom Doust wrote:


I just want to throw some thoughts into the air here about simplifying the
process of adding new bridges.

 

As things stand, with OM 2.1.1.2,  if I want to run a new middleware bridge
I have to add a value to the enum mamaMiddleware

in middleware.h and a case to the switch statement in middleware.c,
effectively forcing a new release of OM if anyone else wants to work with
the new bridge
I agree that this becomes much more cumbersome as we begin to support bridges
from multiple organizations. Requiring new software just to load a new bridge
that is otherwise compatible with your existing version will be frustrating for
many people.

A better solution is for bridges to be self-identifying with required methods
like "getBridgeName", "getBridgeVersion" and maybe "getMinSupportedMamaVersion".


 

Further, I’m constrained to the name of my shared lib though the code in
mama_loadBridgeWithPathInternal and the stuff in platform.c - openSharedLib

that builds the library name. From a development perspective this makes is
difficult to run multiple variants.
If we remove the enums, you can always incorporate a version into the middleware
name like (tick42_dev, tick42_1_0, etc.), and load different versions of the
same bridge.

 

I don’t see any problem with moving the work that is done by the enum/switch
on the middleware name to an external config and also passing the library
name as an optional parameter somewhere, again, possibly read from external
config.

 

There may be some good reasons for things being the way they are, so I’m
interested in any feedback, comments etc, before we (Tick42) consider
contributing some enhancements in this area.

One approach is to get rid of enums and make the bridges self-identifying. The
middleware name simply maps to the library name as it does now, but the new
bridge methods discussed above identify the bridge internally.

We should definitely discuss any proposals in detail before implementing them as
this impacts a lot of bridge developers. Also, we should try very hard to ensure
that existing bridges still load as well.

Regards,
-Mike

 

 

 

TOM DOUST | Head ofConsultancy                                                               
Description: tick42_footer

____________________________________________________________________________

TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@Tick42.com |
http://www.tick42.com  Description: cid:78978EB3-0AAD-4F5A-AD70-E3FE7BA558A5
Description: cid:298E41C4-FA7A-4004-ACAC-439C8094EA5A

____________________________________________________________________________