Re: Proposed minor change to allow specifying named symbol lists


Keith Rudd
 

Classification: Public

To clarify, on

“For your feature are you suggesting that when you request ABC, or would send back a list of either ABC.L, ABCD or both?”

Answer is that either is possible, or something else.

 

I’m not suggesting that we define the semantics of what any particular list contains related to the list symbol name.

I just want it to be possible to pass on a symbol list name to the middleware bridge.

What the list actually represents for that middleware source and if it exists at all, can be middleware-specific and up to the relevant transport to respond on.

All I’m saying when subscribing is “Give me the contents of the symbol list named XXX please”

The symbol list XXX could contain anything or nothing – I have to wait for the response to find out.

 

I don’t think it’s wise to try to specify any universal standard semantics implied in the naming of symbol lists and what they should represent.

Avoid this to allow maximum flexibility to adapt the support for lists to any middleware.

For a middleware/source that supports wildcards it might interpret the ‘*’ char (or others) in a symbol list name as a wildcard, if it is able to support that, but on another source ‘*’ might just be ‘*’.

 

Regards,

Keith

 

From: Glenn McClements [mailto:g.mcclements@...]
Sent: 07 September 2015 12:55
To: Keith Rudd; 'Openmama-dev@...'
Subject: Re: [Openmama-dev] Proposed minor change to allow specifying named symbol lists

 

>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

www.srtechlabs.com

 

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

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



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



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

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