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.
|
||||
|
|
||||
|
mschonberg <mschonberg@...>
On Wed, 25 Jul 2012, Tom Doust wrote:
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". 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. 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
|
||||
|
|
