Hi Folks,

We are currently considering options for trying to make the OpenMAMA API easier to work with and more accessible for new users.

When I look at the OpenMAMA API's strengths and weaknesses, the setup and management of the subscriptions themselves is one of the more difficult things to manage especially with a new user. These are things which we seasoned users would take for granted but I think new users would struggle with.

That is why I'm suggesting a new "MamaResourcePool" api.

The idea is to manage OpenMAMA resources via OpenMAMA itself rather than depending on the user to manage complex state, setup, shutdown etc. I'm taking the approach of starting with what I (pretending to be a new OpenMAMA user) would like to see as opposed to things which would be technically easier to do etc.

So taking for example a new subscription, this is the entire code I'm proposing (in C here but should translate easily to other languages) should be required:

// Set up the event handlers for OpenMAMA

mamaMsgCallbacks callbacks;

memset(&callbacks, 0, sizeof(callbacks));

callbacks.onMsg = subscriptionOnMsg;

callbacks.onCreate = subscriptionOnCreate;

callbacks.onError = subscriptionOnError;

// Use a new "resource pool"

mamaResourcePool resourcePool;

const char* poolName = NULL;

const void* closure = NULL;

// Create the resource pool, allocating queues, defaults etc from configuration

mamaResourcePool_create(&resourcePool, poolName);

// Actually... subscribe to something via something convenient like a URI

mamaResourcePool_createSubscriptionFromUri(&subscription, "bridge://transport/source/topic", &callbacks, closure);

// Block

mama_start();

And then you would start receiving events. No transport creation, source creation, queue creation, encouraging users use default queue etc.

I’d also suggest that the callbacks onCreate and onError should be optional, with the default implementation simply logging those events.

I foresee similar with lambdas etc. The idea is that mamaResourcePool will:

·         When it is created:

o    Create a number of event queues for subscriptions (which could be configurable in properties based on the poolName)

o    Load all payload and middleware bridges found on the PATH / LD_LIBRARY_PATH etc

o    Call mama_open() (if not already open)

o    Create and manage internal stores of all managed subscriptions, transports, sources etc

·         Then when a resource is created inside:

o    Find / create transport bridge

o    Find / create transport

o    Find / create source

o    Find / create subscription (e.g. multiple callbacks for same subscription)

o    Find / create anything which is required to acquire the requested resource

·         Be convenient and usable, but still flexible (it would return existing OpenMama objects so they can be manipulated)

·         Take the heavy lifting and thread safety pain away from the application developer

·         Defer default "is this basic sub" or "is this market data sub" to the bridge, configuration or as an API call in the resource pool itself

My guess is that many of you may already have an API that does this in each of the provided languages… but newcomers won't have that. This would vastly reduce the complexity and error checking required for a new user, as well as remove the expectation around deciding “which subscription API to use” from the application developer.

If there is any feedback to this approach, or in particular if anyone has recently worked with a new user coming online with OpenMAMA please let us know or pop into Gitter to discuss!

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

That’s right Mac users – OpenMAMA has been approved and is now included in homebrew’s set of packages.

So to install OpenMAMA on a Mac, simply

brew update

brew install openmama

…and yes this will also work on the new Apple M1 machines.

This also has been verified as working with linuxbrew (if anyone uses that).

Any issues please raise an issue on the OpenMAMA github page!

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

Hi Folks,

I’m curious about the community feeling towards the future of CentOS. I’d appreciate a reply with one or a selection of the following for those of you running Red Hat derivative distributions:

1. We will be clinging onto CentOS 7 for dear life since CentOS 8 will be EOL 2021 but CentOS 7 won’t be EOL until 2024
2. We will be making the jump to CentOS Stream
3. We will go with one of the CentOS clones
4. We will bide our time and wait to see which CentOS clone comes out on top
5. This doesn’t really affect us – we use RHEL everywhere

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

Hi Folks,

CentOS 6 is reaching its main EOL on the 30^th November (10 days time), so I’d like to ask the community where they are in respect to migration.

Please feel free to reply to me either directly or via list with one of the below:

1. CentOS 6? How quaint. Kill it with fire.
2. We are moving off CentOS 6 and expect to be migrated away from it before the next OpenMAMA release in Spring.
3. I think we’d need CentOS support for at least another year or so until all our systems migrate.

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

Hi Folks,

I am excited to announce that OpenMAMA was successfully contributed to FINOS and it's now available as a FINOS hosted project at https://github.com/finos/OpenMAMA. Any old links and git clones should automatically redirect, but if there are any issues with this please let us know.

Our website is now hosted at openmama.finos.org and you can reach out to the project team using any of the channels on our support page.

Being part of FINOS gives OpenMAMA a specialist target audience to tap into, and helps raise the visibility and profile of the project directly to where it’s likely to be most relevant. We are hoping it will help continue to drive forward with our core goals of adoption, interoperability and visibility.

Many thanks to the FINOS team and to the wider FINOS Community for their warm welcome and support in moving OpenMAMA to its new home!

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

Hi Folks,

We are pleased to announce OpenMAMA 6.3.1 is finally here and has now propagated to Cloudsmith, Maven central etc!

This is a maintenance release which fixes several outstanding bugs and introduces some new functionality.

• Added experimental .NET core support (including C# on Linux)
• Updated supported platforms to include CentOS 8, Ubuntu 18.04 LTS and Ubuntu 20.04 LTS
• Added quickstart / start of tutorial code for all languages
• Modernized JNI implementation to use javac -h rather than javah
• Added json and normalized string methods for all language bindings (formerly reserved for only C)
• Fix multithreaded builds in OpenMAMA and add "experimental" cloudsmith repository automatic upload
• Added support for clang sanitizers
• Added code for creating your own Vagrant box for OpenMAMA (and we uploaded our own)
• Added ansible code for creating a demo environment
• Fixed a few race conditions, leaks and bugs
• Improved Mac Support

For a complete list of all 21 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/11?closed=1

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

Hi Folks,

After a successful testing period (thanks to all who were involved), we are delighted to announce the official launch the new OpenMAMA website which went live yesterday evening: https://openmama.org

We will be getting the word out on social media so please like / share our posts to extend our reach! Also please update any existing links etc. to the OpenMAMA website where appropriate.

The site is a complete overhaul and has several key improvements over the former site beyond aesthetics:

• It is responsive
• It is a static, bloat-free website so it should load very quickly
• You can submit your own suggested changes to the site via pull request because it's all on github
• It merges the documentation and main marketing website into one
• It generally tries to de-duplicate information and the content has had a general refresh

If there are any issues please raise them at https://github.com/OpenMAMA/openmama.github.io/issues and we hope you enjoy the new site! As usual, we’ll be keeping an eye on gitter if you have any immediate feedback / concerns.

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

Hi Folks,

We (finally) have a new RC ready for testing with compiled artifacts for supported platforms – check it out:

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.1-rc1

This is a maintenance release which fixes several outstanding bugs and introduces some new functionality.

• Added .NET core support (includig C# on Linux)
• Updated supported platforms to include CentOS 8, Ubuntu 18.04 LTS and Ubuntu 20.04 LTS
• Added quickstart / start of tutorial code for all languages
• Modernized JNI implementation to use javac -h rather than javah
• Added json and normalized string methods for all language bindings (formerly reserved for only C)
• Fix multithreaded builds in OpenMAMA and add "experimental" cloudsmith repository automatic upload
• Added support for clang sanitizers
• Added code for creating your own Vagrant box for OpenMAMA (and we uploaded our own)
• Added ansible code for creating a demo environment
• Fixed a few race conditions, leaks and bugs
• Improved Mac Support

For a complete list of all 21 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/11?closed=1

The first RC stage will last for 2 weeks, so if no major issues are found, we will provide the GA release on Monday 12^th October 2020.

Good hunting.

Cheers.

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

Hi Folks,

Quick reminder about the invitation below, and to thank everyone who has checked it out already (I can see a noticeable increase in traffic since sending this out so I know you folks are looking).

Particular thanks to our friends at Solace who submitted the first ever pull request to the new website! Others are welcome if appropriate!

Cheers,

Frank

Hi Folks,

It is with great pleasure that I can declare that a new website is on its way.

It is currently hosted at https://openmama.github.io as a preview version (the former documentation website address) and therefore I invite the members of the mailing list to have a look, and report any issues back directly to be before its "proper" launch to openmama.org on Monday 28th September.

The site is a complete overhaul and has several key improvements over the former site beyond aesthetics:

• It is responsive
• It is a static, bloat-free website so it should load very quickly
• You can submit your own suggested changes to the site via pull request because it's all on github
• It merges the documentation and main marketing website into one
• It generally tries to de-duplicate information and the content has had a general refresh

Anyway if there are any issues please raise them at https://github.com/OpenMAMA/openmama.github.io/issues and I hope you enjoy the new site! As usual, I’ll be keeping an eye on gitter if you have any immediate feedback / concerns.

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

Hi Folks,

The default branch for OpenMAMA has now been set to “next”. Looks a little more lively already 😊

If anyone runs into any issues, let me know. Hopefully overall this will make things a little easier.

Cheers,

Frank

Sounds quite sensible to me, Frank.

Hi Folks,

I would like to propose that we change the OpenMAMA github default git branch to “next” instead of “master”.

This would mean that:

• When you visit our github page, you will see the latest development code and documentation
• When you clone the repository, you no longer need to change branch before making feature branches which will eventually become pull requests.

Note all existing clones etc would remain unchanged so this won’t actually “break” anything for existing OpenMAMA developers.

The rationale being that “master” is reflective of the last stable release, but it’s also the source of the main README output when visitors come to the github page which makes it look like the project is less active than it actually is, repo documentation effectively slows down to match the biannual release cycle etc.

The industry in general is also gradually moving away from the “master” nomenclature for branches with linux and github both making noises about moving away from defaulting to that branch name, so this would pave the way for eventual retirement of the branch name (which is actually fine - we can just use our release branches instead as we already do with minimal impact).

If anyone has any comments or feedback on this, please respond on this thread.

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

Hi Folks,

Looks like a number of issues are still coming in and I have identified a few things that I want to get in myself, so I’m going to push this back 1 week to the weekend commencing 28-Aug 2020.

Cheers,

Frank

Hi Folks,

I plan on taking a cut for OpenMAMA 6.3.1 RC1 over the coming weekend (21-Aug 2020). If anyone has anything they want to submit before then please let me know so I can delay the cut if necessary, otherwise I will continue as planned.

This release includes some changes to support:

• CentOS 8
• Fedora 31
• Fedora 32
• Ubuntu 20.04 LTS

It also effectively drops support for the now EOL:

• Fedora 28
• Fedora 29
• Ubuntu 14.04 LTS

This is in preparation for a RC that will be cut within the next few weeks which is now set up to include RPMs and Debian packages for these modern distros to make installation easy, take care of dependencies etc.

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

Hi Folks,

I have just pushed some changes into the next branch which add some changes to support:

• CentOS 8
• Ubuntu 20.04

It also effectively drops support for the now EOL:

• Fedora 28
• Fedora 29
• Ubuntu 14.04 LTS

This is in preparation for a RC that will be cut within the next few weeks which is now set up to include RPMs and Debian packages for these modern distros to make installation easy, take care of dependencies etc.

If you're a user of these new operating system versions, please It a whirl.

Cheers,

Frank

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io