I have some feedback about the RFC for OpenMAMA Source Discovery page: https://openmama.github.io/openmama_rfc_source_discovery.html# I’m pretty much in agreement with delivering the source descriptio

Yes we call back on the bridge’s thread. We don’t queue the message, we leave the client code to do that if it wants to. This is by design.

Hi Yury, Konstantin Are you using the current github version of the bridge code? We looked at and fixed some of the issues around locking the subscription destroy some time back. It would be good to k

I’ve used proboards before in a different context – it works fine but as Frank says its very old-school. My only other comment is that I think there is a lot of value in getting quite tightly integrat

Returning an error sounds fine to me.

One question, (and I haven’t fully thought this through), is there any need to be able to determine at runtime, given a mamaDateTime object, whether it contains an extended value? Tom

I was wondering if we need to think about multiple build targets – user dev, mama runtime, bridge dev etc. Or is that more complicated than necessary. Also, (and I may just be out of date here because

Yeah we have figured out the source code issues and I’ve drawn attention to it on the cmake thread – Its Monday morning J When you have something you want me to try I’m happy to clone it and do a buil

As Reed mentioned we currently use CMake. I think the OpenMAMA devs were considering going there at one point but mysteriously lurched in the direction of Scons within days of Tick42 deciding to use C

Hi Frank I’ve not found it possible to do bridge development (on windows anyway) without building OpenMAMA J It may be possible though. I have just taken a path of least resistance. Let us know if we

In the TREP bridge we have a wrapper around the mamaDateTime type and only use the accessor functions. There is a certain amount of messing around converting between mamaDateTime and rssl date and tim

Hi Holger One thing you need to ensure is that the entnoop library is somewhere in the path that is visible at runtime. This caused us some confusion for a while and may be the cause of the problem th

Hi Holger This sounds familiar. I have forwarded it to our dev who did the 2.4.0 work and I’ll get back to you Tom

Hi Holger There were a few compilation issues (expected) which we have addressed in our internal dev build. I expect to push a new version to github in the next few days Which environment (linux /win)

Hi Nestor I think there is nothing inherent in OpenMAMA that prevents you from creating and running multiple instances of the same transport. I have demonstrated this with the Tick42 TREP bridge. Your

Hi Nestor Do you have mappings for these fields in the field map file? Feel free to mail me a copy of the file directly and I will take a look Best regards Tom TOM DOUST | Head of Consultancy TICK42 P

Hi Nestor, Glenn Order book handling is outside the scope of the current version of our BLP bridge. In our TREP bridge we take OMM MarketByPrice and MarketByOrder messages and build mamda book message

Hi We came across a subtle (and interesting) issue in the .Net implementation. I’m going to describe the problem and how we worked around but I want to open it up for discussion before proposing any f

Hi Holger The blp bridge doesn’t queue the update messages, it just sends them directly on its own thread. I’m aware that the cpp version of mamaproxy uses a detached copy of the incoming message as a

Hi, Many of you will be aware that Tick42 have been developing an OpenMAMA bridge for Thomson Reuters TREP. You may also have noticed that it was publicly announced yesterday. There is a press release