As brought up on a recent thread from Ben:
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.
I have written both enterprise applications based on OpenMAMA as well as internal OpenMAMA code, and as a user, I think mamaMsg_create() without any payload provided is very handy. I think there are a couple of reasons for this:
- mamaMsg_create is one of those functions which you can call from anywhere in your application. It doesn't depend on which bridge you happen to be in during a callback for or anything like that so it can literally come from anywhere. Part of its traditional
appeal is specifically that the application developer doesn't need to consider which payloads are in play, and if he / she does care, there is now a separate _createForPayload method which will provide this level of control.
- mamaMsg_create usually does exactly what the user will want in almost every scenario. If there is only one middleware involved as it's a one sided API (i.e. a MAMA client or a MAMA publisher), the first payload recommended by the bridge is typically what
the user wants to load. It's the same if there is a mid-tier (MAMA pub + sub in one MAMA instance) application where the middlewares are the same north and south.
- Deprecating mamaMsg_create will (I expect) have a reasonably large impact on users as a whole. In fact mamaMsg_createforPayload is actually a new method for users moving from MAMA 5 to OpenMAMA, so migrating customers will never have seen it before.
OK so that's why I think mamaMsg_create() is a nice thing to have wearing my "user hat". Here is where I think it's broken and potential solutions wearing my "bridge developer helmet":
- It makes the default payload library to be the first payload it finds among all payloads. This is OK in most scenarios, but I think there is a notable exception where there is a multi-bridge app present and the preferred payload for bridge 1 is not even
supported by bridge 2. That means any payloads created in this application instance cannot be published by bridge 2 without additional transcoding.
Potential Solution: Wait until all middleware bridges are loaded before selecting a default payload based on which payload bridges exist across all bridges.
- It has no way to be aware of optimal payload selections for each middleware bridge. An example would, again, be in a multi-bridge environment where the algorithm from #1 (let's say) is used to decide a payload compromise, but in the context where a mamaMsg_create
is being called, if you always know that it will only ever be create for use with one middleware bridge, you will want to select whichever payload is preferred for that bridge.
Potential Solution: Have an application-facing way to provide the user with the preferred payload for a given bridge object and then the user can call _createforPayload based on that value.
- For middleware bridges that want to support all possible payload bridges that support serialization and deserialization and possibly don't even have their own payload implementation at all (e.g. ZMQ), they may not wish to select a preference for
which payload bridge to use at all.
Potential Solution: Provide a mama.properties parameter which may be used to find supplementary, user-provided compatible bridges.
So I agree with you in that mamaMsg_create is a little broken, but I think they're all fixable without deprecating a pretty handy convenience function for most users.
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