Re: RFC for Source Discovery
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.
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Tom Doust
Sent: 20 September 2017 12:21
To: fquinn.ni@...; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] RFC for Source Discovery
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.
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
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.
On Behalf Of Frank Quinn
We have a new RFC contributed by Arcontech to cover the upcoming Source Discovery functionality. Thanks very much to the Arcontech folks for taking the time to put this together.
You can find it listed here:
As a reminder of the RFC process and how to get involved, I'll refer you all to:
Pay particular attention to the most constructive ways to provide feedback: https://openmama.github.io/openmama_rfc_process.html#how-to-provide-rfc-feedback
As per our process, we will leave this RFC open for a period of 2 weeks, after which point if there are no major concerns, the RFC design will be considered approved and work can begin.
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 notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.