-----Original Message-----
From: Matthew Mulhern [mailto:MMulhern@...]
Sent: Wednesday, February 06, 2013 9:54 AM
To: openmama-users@...; Joseph Sarbak
Subject: RE:[Openmama-users] Data Dictionary Developer Questions [I]


Addressing each of your points in turn:

0. The default OpenMama topic model is the concatenation of 'namespace'##'symbol'. Can OpenMama support multiple symbols published over a single topic? Would there be any complications (on the caching mechanism, for example) if a group topic model were followed?

OpenMAMA has the concept of group subscriptions, where multiple symbols are sent down a single subscription. It¹s a different subscription type on the client side.
The publisher needs to send an initial for each symbol within the group before the 10 second timeout elapses.
The specific symbol within the group is communicated using the wIssueSymbol reserved field.
Each symbol has a separate context and has its own sequence numbers and gap detection.


1. Data Dictionary API: Can one enrish the standard field description with user-defined fields? Example custom fields would be: custom data-types, and byte-offset?

Yes, there is a dedicated range for adding your own custom fields.
However the types available in the dictionary may be a lot less strict than the payload. Generally the dictionary is used for Name/fid mapping.


2. Data Dictionary API: Is there java support? Is there a plan for supporting java?

There is a MamaDIctionary in JAVA currently. However it relies on populating from a file or a msg.



Rgds,
Matt Mulhern

On 04/02/2013 19:30, "Joseph Sarbak" <joseph.sarbak@...> wrote:

Classification: For internal use only

Dear openmama-users@...,

For my employer, I am investigating the work required to publish
market data to internal consumers over the OpenMama API. I have a
couple questions regarding the default mama topic model and the data
dictionary api. I would be very grateful if someone could either
answer these questions or indicate whether I should be asking another mailing list.


0. The default OpenMama topic model is the concatenation of
'namespace'##'symbol'. Can OpenMama support multiple symbols
published over a single topic? Would there be any complications (on
the caching mechanism, for example) if a group topic model were followed?

1. Data Dictionary API: Can one enrish the standard field description
with user-defined fields? Example custom fields would be: custom
data-types, and byte-offset?

2. Data Dictionary API: Is there java support? Is there a plan for
supporting java?

Thank you.

Joseph Sarbak


---
This communication may contain confidential and/or privileged
information. If you are not the intended recipient (or have received
this communication in error) please notify the sender immediately and
destroy this communication. Any unauthorized copying, disclosure or
distribution of the material in this communication is strictly forbidden.

Deutsche Bank does not render legal or tax advice, and the information
contained in this communication should not be regarded as such.
_______________________________________________
Openmama-users mailing list
Openmama-users@...
https://lists.openmama.org/mailman/listinfo/openmama-users

________________________________

Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

---
This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.

Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.