Re: RFC for Source Discovery


Keith Rudd
 

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

 

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.

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

 

TOM DOUST | Head of  Consultancy                                                                                             

TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@... | skype: tom.doust|  http://www.tick42.com

 

 

 

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: 13 September 2017 11:53
To: openmama-dev <openmama-dev@...>
Subject: [Openmama-dev] RFC for Source Discovery

 

Hi Folks,

 

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.

 

Cheers,

Frank



---
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.

Join Openmama-dev@lists.openmama.org to automatically receive all group messages.