problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded
|
Damian Maguire
Cheers for this Tom, looks good. Standard practice to proceed with this one - firstly can you raise a Bugzilla ticket for tracking, and secondly can you provide some tests demonstrating the use of the new API? Ideally a set of unit tests which show the usage in various combinations would be ideal. Let me know if you have any other questions. Cheers, Damian On Fri, Sep 5, 2014 at 10:26 AM, Tom Doust <tom.doust@...> wrote:
|
||||
|
|
||||
|
Tom Doust
Hi Glenn
I’m resubmitting that patch (attached and below). This now conforms with your comments
Tom
diff --git a/README b/README index be1ad38..f278d0d 100644 --- a/README +++ b/README @@ -2,7 +2,7 @@ OpenMAMA Client Library ============================
Release: 2.3.1 -Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1 +Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release
Project Page ------------ diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c index 7f7d605..a4e6cdf 100644 --- a/mama/c_cpp/src/c/dictionary.c +++ b/mama/c_cpp/src/c/dictionary.c @@ -495,6 +495,20 @@ mamaDictionary_getDictionaryMessage ( return MAMA_STATUS_OK; }
+mama_status mamaDictionary_populateDictionaryMessage( + mamaDictionary dictionary, + mamaMsg msg) +{ + mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary; + + if (!impl) return MAMA_STATUS_NULL_ARG; + if (!msg) return MAMA_STATUS_INVALID_ARG; + + populateMessageFromDictionary (impl, msg); + + return MAMA_STATUS_OK; +} + mama_status mamaDictionary_createFieldDescriptor ( mamaDictionary dictionary, diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h index 0eda958..faa7fe8 100644 --- a/mama/c_cpp/src/c/mama/dictionary.h +++ b/mama/c_cpp/src/c/mama/dictionary.h @@ -268,6 +268,20 @@ mamaDictionary_getDictionaryMessage ( mamaMsg* msg);
/** + * Fill a message with the data dictionary. + * + * An existing mama message is populated fromt he data dictionary + * This allows the caller to create the message on a specifc payload + * + * @param dictionary The Dictionary + * @param msg The address of the mamaMsg where the result is to be written + */ +MAMAExpDLL extern mama_status mamaDictionary_populateDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg msg); + + +/** * Create a new field descriptor and add it to the dictionary. * New fields can be added to an existing dictionary obtained * from the MAMA infrastructure. This function can also be used
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Tom Doust
Sent: 03 September 2014 4:37 PM To: Glenn McClements; Openmama-dev@... Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded
Hi Glenn
Both of those of those points are accepted and I’ll re-submit a patch in a couple of days when I can get this back to the top of my todo list J
Is this function ever used anywhere other than in a bridge? We only use it in the context of a bridge building a message from the dictionary in order to publish it
Tom
From: Glenn McClements [mailto:gmcclements@...]
Cheers Tom.
I think this way is cleaner than passing in a payload ID or bridge to the dictionary functions, as it keeps all the payload specific stuff in the mamaMsg calls where it belongs.
Two minor points about the signature:
- I'd prefer 'populate' rather than 'fill', as populate is used elsewhere in the API - There's no need for it to be pointer to a mamaMsg
As always, C++, .Net and Java/JNI will need this to be updated as well.
Also to note that we'll be deprecating the use of the payload enum identifier in favour of a bridge handle. This won't make a difference to this way of doing it though.
Glenn
From:
openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Tom Doust [tom.doust@...] Hi
Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.
We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)
// Prepare the OpenMAMA dictionary part of the message #if defined(MAMA_DICTIONARY_PATCH) // provided mama has been patched for the new dictionary function we can create our own message on our own payload mamaMsg dictMsg=NULL; mamaMsg_createForPayload(&dictMsg, 'P'); mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg); #else mamaMsg dictMsg=NULL; mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg); #endif
As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.
I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject
Best regards
Tom
The patch is also shown below
diff --git a/README b/README index be1ad38..f278d0d 100644 --- a/README +++ b/README @@ -2,7 +2,7 @@ OpenMAMA Client Library ============================ Release: 2.3.1 -Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1 +Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release Project Page ------------ diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c index 7f7d605..8a6d275 100644 --- a/mama/c_cpp/src/c/dictionary.c +++ b/mama/c_cpp/src/c/dictionary.c @@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage ( } mama_status + mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg) +{ + mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary; + + if (!impl) return MAMA_STATUS_NULL_ARG; + if (!msg) return MAMA_STATUS_INVALID_ARG; + + populateMessageFromDictionary (impl, *msg); + + return MAMA_STATUS_OK; +} + +mama_status mamaDictionary_createFieldDescriptor ( mamaDictionary dictionary, mama_fid_t fid, diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h index 0eda958..40f7885 100644 --- a/mama/c_cpp/src/c/mama/dictionary.h +++ b/mama/c_cpp/src/c/mama/dictionary.h @@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage ( mamaMsg* msg); /** + * Fill a message with the data dictionary. + * + * An existing mama message is populated fromt he data dictionary + * This allows the caller to create the message on a specifc payload + * + * @param dictionary The Dictionary + * @param msg The address of the mamaMsg where the result is to be written + */ +MAMAExpDLL +extern mama_status +mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg); + + +/** * Create a new field descriptor and add it to the dictionary. * New fields can be added to an existing dictionary obtained * from the MAMA infrastructure. This function can also be used
From: Tom Doust
Hi
mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)
creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.
Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.
I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.
I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.
Tom
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
||||
|
|
||||
|
Glenn McClements <gmcclements@...>
It would generally be used in publishing applications, but as it's public I've no visibility how much it's used in the wild in other places.
We're also looking at some cross platform macros for deprecating functions, so we can consider mamaDictionary_getDictionaryMessage() to be officially marked as deprecated when _populate is
put in.
Glenn From: Tom Doust [tom.doust@...]
Sent: 03 September 2014 11:37 To: Glenn McClements; Openmama-dev@... Subject: RE: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded Hi Glenn
Both of those of those points are accepted and I’ll re-submit a patch in a couple of days when I can get this back to the top of my todo list J
Is this function ever used anywhere other than in a bridge? We only use it in the context of a bridge building a message from the dictionary in order to publish it
Tom
From: Glenn McClements [mailto:gmcclements@...]
Cheers Tom.
I think this way is cleaner than passing in a payload ID or bridge to the dictionary functions, as it keeps all the payload specific stuff in the mamaMsg calls where it belongs.
Two minor points about the signature:
- I'd prefer 'populate' rather than 'fill', as populate is used elsewhere in the API - There's no need for it to be pointer to a mamaMsg
As always, C++, .Net and Java/JNI will need this to be updated as well.
Also to note that we'll be deprecating the use of the payload enum identifier in favour of a bridge handle. This won't make a difference to this way of doing it though.
Glenn
From:
openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Tom Doust [tom.doust@...] Hi
Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.
We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)
// Prepare the OpenMAMA dictionary part of the message #if defined(MAMA_DICTIONARY_PATCH) // provided mama has been patched for the new dictionary function we can create our own message on our own payload mamaMsg dictMsg=NULL; mamaMsg_createForPayload(&dictMsg, 'P'); mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg); #else mamaMsg dictMsg=NULL; mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg); #endif
As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.
I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject
Best regards
Tom
The patch is also shown below
diff --git a/README b/README index be1ad38..f278d0d 100644 --- a/README +++ b/README @@ -2,7 +2,7 @@ OpenMAMA Client Library ============================ Release: 2.3.1 -Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1 +Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release Project Page ------------ diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c index 7f7d605..8a6d275 100644 --- a/mama/c_cpp/src/c/dictionary.c +++ b/mama/c_cpp/src/c/dictionary.c @@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage ( } mama_status + mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg) +{ + mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary; + + if (!impl) return MAMA_STATUS_NULL_ARG; + if (!msg) return MAMA_STATUS_INVALID_ARG; + + populateMessageFromDictionary (impl, *msg); + + return MAMA_STATUS_OK; +} + +mama_status mamaDictionary_createFieldDescriptor ( mamaDictionary dictionary, mama_fid_t fid, diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h index 0eda958..40f7885 100644 --- a/mama/c_cpp/src/c/mama/dictionary.h +++ b/mama/c_cpp/src/c/mama/dictionary.h @@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage ( mamaMsg* msg); /** + * Fill a message with the data dictionary. + * + * An existing mama message is populated fromt he data dictionary + * This allows the caller to create the message on a specifc payload + * + * @param dictionary The Dictionary + * @param msg The address of the mamaMsg where the result is to be written + */ +MAMAExpDLL +extern mama_status +mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg); + + +/** * Create a new field descriptor and add it to the dictionary. * New fields can be added to an existing dictionary obtained * from the MAMA infrastructure. This function can also be used
From: Tom Doust
Hi
mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)
creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.
Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.
I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.
I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.
Tom
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
||||
|
|
||||
|
Tom Doust
Hi Glenn
Both of those of those points are accepted and I’ll re-submit a patch in a couple of days when I can get this back to the top of my todo list J
Is this function ever used anywhere other than in a bridge? We only use it in the context of a bridge building a message from the dictionary in order to publish it
Tom
From: Glenn McClements [mailto:gmcclements@...]
Sent: 03 September 2014 4:29 PM To: Tom Doust; Openmama-dev@... Subject: RE: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded
Cheers Tom.
I think this way is cleaner than passing in a payload ID or bridge to the dictionary functions, as it keeps all the payload specific stuff in the mamaMsg calls where it belongs.
Two minor points about the signature:
- I'd prefer 'populate' rather than 'fill', as populate is used elsewhere in the API - There's no need for it to be pointer to a mamaMsg
As always, C++, .Net and Java/JNI will need this to be updated as well.
Also to note that we'll be deprecating the use of the payload enum identifier in favour of a bridge handle. This won't make a difference to this way of doing it though.
Glenn
From:
openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Tom Doust [tom.doust@...] Hi
Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.
We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)
// Prepare the OpenMAMA dictionary part of the message #if defined(MAMA_DICTIONARY_PATCH) // provided mama has been patched for the new dictionary function we can create our own message on our own payload mamaMsg dictMsg=NULL; mamaMsg_createForPayload(&dictMsg, 'P'); mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg); #else mamaMsg dictMsg=NULL; mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg); #endif
As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.
I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject
Best regards
Tom
The patch is also shown below
diff --git a/README b/README index be1ad38..f278d0d 100644 --- a/README +++ b/README @@ -2,7 +2,7 @@ OpenMAMA Client Library ============================ Release: 2.3.1 -Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1 +Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release Project Page ------------ diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c index 7f7d605..8a6d275 100644 --- a/mama/c_cpp/src/c/dictionary.c +++ b/mama/c_cpp/src/c/dictionary.c @@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage ( } mama_status + mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg) +{ + mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary; + + if (!impl) return MAMA_STATUS_NULL_ARG; + if (!msg) return MAMA_STATUS_INVALID_ARG; + + populateMessageFromDictionary (impl, *msg); + + return MAMA_STATUS_OK; +} + +mama_status mamaDictionary_createFieldDescriptor ( mamaDictionary dictionary, mama_fid_t fid, diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h index 0eda958..40f7885 100644 --- a/mama/c_cpp/src/c/mama/dictionary.h +++ b/mama/c_cpp/src/c/mama/dictionary.h @@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage ( mamaMsg* msg); /** + * Fill a message with the data dictionary. + * + * An existing mama message is populated fromt he data dictionary + * This allows the caller to create the message on a specifc payload + * + * @param dictionary The Dictionary + * @param msg The address of the mamaMsg where the result is to be written + */ +MAMAExpDLL +extern mama_status +mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg); + + +/** * Create a new field descriptor and add it to the dictionary. * New fields can be added to an existing dictionary obtained * from the MAMA infrastructure. This function can also be used
From: Tom Doust
Hi
mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)
creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.
Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.
I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.
I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.
Tom
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
||||
|
|
||||
|
Glenn McClements <gmcclements@...>
Also having the user create the message makes it explicit who owns the memory which I like as well.
Glenn From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Glenn McClements [gmcclements@...]
Sent: 03 September 2014 11:28 To: Tom Doust; Openmama-dev@... Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded Cheers Tom.
I think this way is cleaner than passing in a payload ID or bridge to the dictionary functions, as it keeps all the payload specific stuff in the mamaMsg calls where it belongs.
Two minor points about the signature:
- I'd prefer 'populate' rather than 'fill', as populate is used elsewhere in the API
- There's no need for it to be pointer to a mamaMsg
As always, C++, .Net and Java/JNI will need this to be updated as well.
Also to note that we'll be deprecating the use of the payload enum identifier in favour of a bridge handle. This won't make a difference to this way of doing it though.
Glenn
From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Tom Doust [tom.doust@...]
Sent: 03 September 2014 09:56 To: Openmama-dev@... Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded Hi
Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.
We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)
// Prepare the OpenMAMA dictionary part of the message #if defined(MAMA_DICTIONARY_PATCH) // provided mama has been patched for the new dictionary function we can create our own message on our own payload mamaMsg dictMsg=NULL; mamaMsg_createForPayload(&dictMsg, 'P'); mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg); #else mamaMsg dictMsg=NULL; mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg); #endif
As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.
I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject
Best regards
Tom
The patch is also shown below
diff --git a/README b/README index be1ad38..f278d0d 100644 --- a/README +++ b/README @@ -2,7 +2,7 @@ OpenMAMA Client Library ============================
Release: 2.3.1 -Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1 +Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release
Project Page ------------ diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c index 7f7d605..8a6d275 100644 --- a/mama/c_cpp/src/c/dictionary.c +++ b/mama/c_cpp/src/c/dictionary.c @@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage ( }
mama_status + mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg) +{ + mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary; + + if (!impl) return MAMA_STATUS_NULL_ARG; + if (!msg) return MAMA_STATUS_INVALID_ARG; + + populateMessageFromDictionary (impl, *msg); + + return MAMA_STATUS_OK; +} + +mama_status mamaDictionary_createFieldDescriptor ( mamaDictionary dictionary, mama_fid_t fid, diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h index 0eda958..40f7885 100644 --- a/mama/c_cpp/src/c/mama/dictionary.h +++ b/mama/c_cpp/src/c/mama/dictionary.h @@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage ( mamaMsg* msg);
/** + * Fill a message with the data dictionary. + * + * An existing mama message is populated fromt he data dictionary + * This allows the caller to create the message on a specifc payload + * + * @param dictionary The Dictionary + * @param msg The address of the mamaMsg where the result is to be written + */ +MAMAExpDLL +extern mama_status +mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg); + + +/** * Create a new field descriptor and add it to the dictionary. * New fields can be added to an existing dictionary obtained * from the MAMA infrastructure. This function can also be used
From: Tom Doust
Hi
mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)
creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.
Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.
I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.
I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.
Tom
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
||||
|
|
||||
|
Glenn McClements <gmcclements@...>
Cheers Tom.
I think this way is cleaner than passing in a payload ID or bridge to the dictionary functions, as it keeps all the payload specific stuff in the mamaMsg calls where it belongs.
Two minor points about the signature:
- I'd prefer 'populate' rather than 'fill', as populate is used elsewhere in the API
- There's no need for it to be pointer to a mamaMsg
As always, C++, .Net and Java/JNI will need this to be updated as well.
Also to note that we'll be deprecating the use of the payload enum identifier in favour of a bridge handle. This won't make a difference to this way of doing it though.
Glenn
From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Tom Doust [tom.doust@...]
Sent: 03 September 2014 09:56 To: Openmama-dev@... Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded Hi
Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.
We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)
// Prepare the OpenMAMA dictionary part of the message #if defined(MAMA_DICTIONARY_PATCH) // provided mama has been patched for the new dictionary function we can create our own message on our own payload mamaMsg dictMsg=NULL; mamaMsg_createForPayload(&dictMsg, 'P'); mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg); #else mamaMsg dictMsg=NULL; mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg); #endif
As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.
I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject
Best regards
Tom
The patch is also shown below
diff --git a/README b/README index be1ad38..f278d0d 100644 --- a/README +++ b/README @@ -2,7 +2,7 @@ OpenMAMA Client Library ============================
Release: 2.3.1 -Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1 +Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release
Project Page ------------ diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c index 7f7d605..8a6d275 100644 --- a/mama/c_cpp/src/c/dictionary.c +++ b/mama/c_cpp/src/c/dictionary.c @@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage ( }
mama_status + mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg) +{ + mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary; + + if (!impl) return MAMA_STATUS_NULL_ARG; + if (!msg) return MAMA_STATUS_INVALID_ARG; + + populateMessageFromDictionary (impl, *msg); + + return MAMA_STATUS_OK; +} + +mama_status mamaDictionary_createFieldDescriptor ( mamaDictionary dictionary, mama_fid_t fid, diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h index 0eda958..40f7885 100644 --- a/mama/c_cpp/src/c/mama/dictionary.h +++ b/mama/c_cpp/src/c/mama/dictionary.h @@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage ( mamaMsg* msg);
/** + * Fill a message with the data dictionary. + * + * An existing mama message is populated fromt he data dictionary + * This allows the caller to create the message on a specifc payload + * + * @param dictionary The Dictionary + * @param msg The address of the mamaMsg where the result is to be written + */ +MAMAExpDLL +extern mama_status +mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg); + + +/** * Create a new field descriptor and add it to the dictionary. * New fields can be added to an existing dictionary obtained * from the MAMA infrastructure. This function can also be used
From: Tom Doust
Hi
mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)
creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.
Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.
I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.
I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.
Tom
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
||||
|
|
||||
|
Tom Doust
Hi
Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.
We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)
// Prepare the OpenMAMA dictionary part of the message #if defined(MAMA_DICTIONARY_PATCH) // provided mama has been patched for the new dictionary function we can create our own message on our own payload mamaMsg dictMsg=NULL; mamaMsg_createForPayload(&dictMsg, 'P'); mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg); #else mamaMsg dictMsg=NULL; mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg); #endif
As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.
I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject
Best regards
Tom
The patch is also shown below
diff --git a/README b/README index be1ad38..f278d0d 100644 --- a/README +++ b/README @@ -2,7 +2,7 @@ OpenMAMA Client Library ============================
Release: 2.3.1 -Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1 +Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release
Project Page ------------ diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c index 7f7d605..8a6d275 100644 --- a/mama/c_cpp/src/c/dictionary.c +++ b/mama/c_cpp/src/c/dictionary.c @@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage ( }
mama_status + mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg) +{ + mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary; + + if (!impl) return MAMA_STATUS_NULL_ARG; + if (!msg) return MAMA_STATUS_INVALID_ARG; + + populateMessageFromDictionary (impl, *msg); + + return MAMA_STATUS_OK; +} + +mama_status mamaDictionary_createFieldDescriptor ( mamaDictionary dictionary, mama_fid_t fid, diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h index 0eda958..40f7885 100644 --- a/mama/c_cpp/src/c/mama/dictionary.h +++ b/mama/c_cpp/src/c/mama/dictionary.h @@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage ( mamaMsg* msg);
/** + * Fill a message with the data dictionary. + * + * An existing mama message is populated fromt he data dictionary + * This allows the caller to create the message on a specifc payload + * + * @param dictionary The Dictionary + * @param msg The address of the mamaMsg where the result is to be written + */ +MAMAExpDLL +extern mama_status +mamaDictionary_fillDictionaryMessage ( + mamaDictionary dictionary, + mamaMsg* msg); + + +/** * Create a new field descriptor and add it to the dictionary. * New fields can be added to an existing dictionary obtained * from the MAMA infrastructure. This function can also be used
From: Tom Doust
Sent: 29 August 2014 10:12 AM To: Openmama-dev@... Subject: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded
Hi
mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)
creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.
Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.
I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.
I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.
Tom
|
||||
|
|
||||
|
Damian Maguire
Hey Tom, I think the idea of an additional method for populating a message with a dictionary is spot on - something which passes in a pre-created message and fills it with the dictionary contents as in your second suggestion seems like a good fit to me. If you'd like to put together a patch and send it through to the list, I think that would help get the discussion going and maybe shake out some usecases we haven't thought of.
Cheers, Damian On Fri, Aug 29, 2014 at 10:12 AM, Tom Doust <tom.doust@...> wrote:
|
||||
|
|
||||
|
Tom Doust
Hi
mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)
creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.
Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.
I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.
I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.
Tom
|
||||
|
|
