Hi Folks,

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:

1. 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.
2. 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.
3. 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":

1. 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.
2. 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.
3. 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.

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

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.