Re: Proposed minor change to allow specifying named symbol lists
|
Glenn McClements <g.mcclements@...>
>I’m not really sure on the semantics of why you need different types of list requests for BOOK or GROUP symbols – is the returned data not still just a list of symbols in field ‘MamaSymbolList’ ?
It is, but for feed handlers that support L1 and L2 (and GROUP), then you can restrict
the symbol set that is provided.
>So if I specify say source ‘LSE’, symbol ‘VOD’ for my SYMBOL_LIST request, my expected response might be the list of all symbols representing options for ‘VOD’ from source ‘LSE’.
So is this effectively VOD.*, or VOD*? It’s possible that a symbol from a publisher is a sub string of another symbol. Consider the symbols below: ABC ABC.L ABCD
For your feature are you suggesting that when you request ABC, or would send back a list of either ABC.L, ABCD or both?
Just trying to formalise this a bit so there’s no ambiguity with publishers – a set of examples would help as well.
Cheers, Glenn
Glenn McClements, SVP Engineering Adelaide Exchange, 24-26 Adelaide Street, Belfast, UK, BT2 8GD
SR.LABS Proven High Speed Electronic Trading Solutions
From: Keith Rudd
Date: Thursday, 3 September 2015 11:25 To: Glenn McClements, "'Openmama-dev@...'" Subject: RE: [Openmama-dev] Proposed minor change to allow specifying named symbol lists Classification: Public Glenn,
Thanks for explaining this a bit.
I’m not really sure on the semantics of why you need different types of list requests for BOOK or GROUP symbols – is the returned data not still just a list of symbols in field ‘MamaSymbolList’ ? Maybe some of the feed handlers need to know this if symbols only exist as L1 or L2, not both? (You could handle that with different symbol names – e.g. “ALL_L1”, “ALL_L2” – whatever the source publisher wanted to support)
The ‘source’ field is still used and required. So if I specify say source ‘LSE’, symbol ‘VOD’ for my SYMBOL_LIST request, my expected response might be the list of all symbols representing options for ‘VOD’ from source ‘LSE’. The actual symbol list names supported and what they represent for any given source would be up to the feed handler (source publisher).
You could certainly allow a wildcard char to be specified within the ‘symbol’ parameter, but again it would be up to source publishers whether they recognized and supported requests for symbol lists (or groups) with names containing wildcards. Nothing extra is required here in the MAMA layer to include/exclude support for wildcard symbol names.
Regards, Keith
From: Glenn McClements [mailto:g.mcclements@...]
Sent: 02 September 2015 16:43 To: Keith Rudd; 'Openmama-dev@...' Subject: Re: [Openmama-dev] Proposed minor change to allow specifying named symbol lists
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
SR.LABS Proven High Speed Electronic Trading Solutions
From: <openmama-dev-bounces@...> on behalf of Keith Rudd
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 |
|
|