Re: Proposed minor change to allow specifying named symbol lists


Glenn McClements <g.mcclements@...>
 

Hi Keith,

"Also, there are actually two similar subscription types that can be used:

MAMA_SUBSC_TYPE_SYMBOL_LIST and MAMA_SUBSC_TYPE_SYMBOL_LIST_NORMAL

The intended different use for these is not clear – they both are processed exactly the same.

Can anyone shed light on the reason for both existing?


MAMA_SUBSC_TYPE_SYMBOL_LIST_NORMAL is a hint to the publisher on what type of symbols should be returned, NORMAL is L1 data.  The symbol list sub types map tot he may to the subscription types of NORMAL, BOOK and GROUP, ie. 

	- MAMA_SUBSC_TYPE_SYMBOL_LIST_NORMAL
        - MAMA_SUBSC_TYPE_SYMBOL_LIST_GROUP
        - MAMA_SUBSC_TYPE_SYMBOL_LIST_BOOK

MAMA_SUBSC_TYPE_SYMBOL_LIST was the original type (replaced by the ones above) but can still be used for backward compatibility. 


With regards to your suggested change it makes sense. My main thoughts would be how the logic around how the “symbol” field is mapped to a “source”? 

Should this be made more explicit with a “source” field? 

Should it be of the format “SOURCE" or "SOURCE.”?

Should wildcards or regex be supported or explicitly not supported (for now)?


Cheers,

Glenn 



Glenn McClements, SVP Engineering 

Adelaide Exchange, 24-26 Adelaide Street,  Belfast, UK, BT2 8GD

www.srtechlabs.com

 

SR.LABS Proven High Speed Electronic Trading Solutions


From: <openmama-dev-bounces@...> on behalf of Keith Rudd
Date: Wednesday, 2 September 2015 11:20
To: "'Openmama-dev@...'"
Subject: [Openmama-dev] Proposed minor change to allow specifying named symbol lists

Classification: Public

With the current OpenMAMA functionality for symbol list type requests (MAMA_SUBSC_TYPE_SYMBOL_LIST), it is not possible to request a named symbol list.

 

Any symbol name specified is ignored and overwritten by “SYMBOL_LIST_NORMAL”.

The assumed semantics is that you always want a list of the entire list of symbols available for the specified source.

 

This is unnecessarily restrictive. There is no reason why the middleware might not support symbol lists representing other named subsets of the source data, such as all the options for an underlier or all the contracts for a future.

(TREP sources typically do support this for example, but the concept of named symbol lists is by no means TREP-specific)

 

With a very simple modification, this could be supported.

Just by not overwriting the symbol name if one is specified.

The current behavior can be preserved as the default for backwards-compatibility, by still overwriting with “SYMBOL_LIST_NORMAL” if no symbol is specified.

 

Also, there are actually two similar subscription types that can be used:

MAMA_SUBSC_TYPE_SYMBOL_LIST and MAMA_SUBSC_TYPE_SYMBOL_LIST_NORMAL

The intended different use for these is not clear – they both are processed exactly the same.

Can anyone shed light on the reason for both existing?

One of these could also be preserved as is for another backward-compatibility option.

 

A minor change to subscription.c only is required.

Optionally, minor change to subscriptiontype.c, subsctype.c to differentiate between the two types of symbol list request.

 

I can’t actually contribute to GIT repository myself, so hope someone else will look kindly on this proposed change to implement it!

 

I can see no downside.

 

Regards,

Keith

 



---
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 http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC

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