Re: General MAMA feature / project questions
Mike Schonberg <mschonberg@...>
On Wed, 9 May 2012, Noah Zucker wrote:
Greetings all. I'm getting started with OpenMAMA here at NYSE and had themama_open() by default attempts to load properties from
mama_openWithProperties(path, filename) initializes OpenMAMA reading the
properties from path/filename rather than $WOMBAT_PATH/mama.properties.
mama_getProperty(const char* name) returns the property value given the property
mama_setProperty(...) alows applications to set/modify properties
mama_setPropertiesFromFile(path, filename) loads additional properties from the
common/c_cpp/src/c/property.h defines the low level interface for manipulating
property files. It uses the flex grammar defined in common/.../c/properties.l to
parse properties files.
Bridges should use mama_getProperty() to access properties. Bridges should
prefix all properties with "mama.<bridge_name>". The canonical form is
"mama.<bridge_name>.<category>.[<name>].property". The optional name allows for
multiple "named" configurations. For example,
mama.some_middleware.transport.my_transport.broker_address=127.0.0.1 defines the
broker address for a transported named "my_transport" on some_middleware.
1c) Do I have to parse the strings myself, or can I provide just theThe properties parser only knows how to parse the file into name value pairs so
bridges need to interpret the resulting value strings. There are a few helper
functions like strtobool() in common/.../c/wombat/strutils.h; however it might
be nice to start building a well defined library of property parsers/validators
standard types (IP addresses, integers, comma delimited lists, etc.).
1d) How / where do I define the configuration parameters that are settable inI suggest that you create properties.h file for your bridge with macros for
all your properties and a properties.c file with functions to read and interpret
Currently the Avis message payload is the only open source payload. Since
payloads are not dependent on middleware, it should be possible to use the Avis
payload with other middleware bridges.
We are currently investigating other potential FOSS payload implementations. One
interesting possibility is Google Protocol Buffers.
MAMA currently contains default implementations for queues and timers. I would
like to see a default implemenatation for IO Events as well. Since most
applications do not use IO Events, implementing them is optional.
"make clean" should get rid of most of them.
I also find "git clean -d -f" useful (WARNING: THIS WILL DELETE ALL UNTRACKED
FILES SO MAKE SURE THAT YOU HAVE STASHED, OR ADDED ALL NEW SOURCE FILES FIRST).
We should also get out of tree builds working as this minimizing the noise in
the source directory.
Configure.ac takes care of this.
In general you run "configure --with-<middlware_name>" to indicate which
bridge(s) you want to build. In the future, I would like to add an option that
builds all middlewares for which configure can locate valid libraries.
You can configure with --without-middleware-bridge and no bridge will be built.
Likewise you can specify --without-payload-bridge to build without a payload
Please consider the environment before printing this email.
Visit our website at http://www.nyse.com
Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to 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 the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext.