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 descriptions and notification encoded in MAMA messages, it significantly reduces the work required to deliver an implementation and also simplifies things for application writers.

However, I’d like to suggest that rather than build a new API around a notional “source discovery object” as the RFC suggests, we simply make requests on the existing market data subscription API and differentiate by specifying a “special” source name (similar to how dictionary subscriptions are made ) This will work for both initial “discovered source” messages and updates to source status. This approach works well enough in the Tick42 TREP bridge. The main benefit of this approach is that in its simplest form it requires NO code to be written in the mama infrastructure and avoids having to replicate the API across each of the language bindings.

All the additional code devolves to the bridge implementation – this has to be written anyway. The special source name can be either fixed, hard coded in some way, or configurable through the mama.properties file. Although we would probably all agree as programmers it should be configurable, I can’t really think of a strong reason why J

I think that defining the fields as properties as indicated is necessary as it effectively defines the message schema but there are a couple of potential issues that are not covered by the RFC

• Fid clashes. If the fids are defined as properties by the mama infrastructure there is a risk that they will overlap with fids defined in a dictionary posted by a bridge. This may not necessarily be a problem as the context may resolve any such clashes but nevertheless it might be worth exploring ways to avoid this
• I think the fields need to be typed. Mostly they will be strings but some might be bool or int. This requires another property for each.

Is it possible to attribute a source with a data dictionary? I suspect that currently the assumptions made about field names in some of the MAMDA code effectively limit to a single data dictionary. This is an area that needs to be carefully explored and potentially tidied up.

Best regards

Tom Doust

Classification: Public

My feedback:

Why was extending the existing MamaTransport Callback interface not considered as an approach?

All sources are available only in the context of a Mama Transport.

Middleware bridges already can use the Transport Callback interface to inform when the transport is connected, disconnected, has a data quality change etc.

It seems a fairly logical extension to me for basically the same mechanism (with an extra callback or two) to be used to relay other information about this connection (transport), including what sources are available on it, changes to the status of those, if that info becomes available.

I agree with the requirement to provide info on source names as strings, ids as integers.

For capabilities, using strings is perhaps best in practice to cope with the fact that the list of possible capabilities could change and may not be completely definable up front.

We need some standardization around this though (defined set of strings?) since I can see people wanting to process this capability info automatically and it is reasonable to expect that exactly equivalent capabilities could be provided by different middlewares – need to ensure they name them the same way in that case.

Regards,

Keith