RFC for Extended MAMA Date Time
|
Frank Quinn <fquinn@...>
Hi Folks,
I have just opened up a new RFC to cover the upcoming Extended MAMA Date Time functionality. You can find it listed here:
https://openmama.github.io/openmama_rfc_open.html
Also note that in the interest of making this process completely transparent, I have also created a process document outlining how we review RFCs and guidelines on how to create them going forward:
https://openmama.github.io/openmama_rfc_process.html
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
FRANK QUINN Principal Engineer, Europe
O. +44 289 568 0209 x3592
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
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. Vela Trading Technologies LLC |
|
|
|
Alpert, Reed <reed.alpert@...>
Hi,
This looks good for JPMChase, we will be able to support our securities before 1970 and far into the future.
Thanks,
Reed.
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Frank Quinn
Sent: Tuesday, December 13, 2016 6:21 AM To: openmama-dev Subject: [Openmama-dev] RFC for Extended MAMA Date Time
Hi Folks,
I have just opened up a new RFC to cover the upcoming Extended MAMA Date Time functionality. You can find it listed here:
https://openmama.github.io/openmama_rfc_open.html
Also note that in the interest of making this process completely transparent, I have also created a process document outlining how we review RFCs and guidelines on how to create them going forward:
https://openmama.github.io/openmama_rfc_process.html
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
FRANK QUINN Principal Engineer, Europe
O. +44 289 568 0209 x3592
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. |
|
|
|
Tom Doust
One question, (and I haven’t fully thought this through), is there any need to be able to determine at runtime, given a mamaDateTime object, whether it contains an extended value?
Tom
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Alpert, Reed via Openmama-dev
Sent: 13 December 2016 22:12 To: Frank Quinn <fquinn@...>; openmama-dev <openmama-dev@...> Subject: Re: [Openmama-dev] RFC for Extended MAMA Date Time
Hi,
This looks good for JPMChase, we will be able to support our securities before 1970 and far into the future.
Thanks,
Reed.
From:
openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Frank Quinn
Hi Folks,
I have just opened up a new RFC to cover the upcoming Extended MAMA Date Time functionality. You can find it listed here:
https://openmama.github.io/openmama_rfc_open.html
Also note that in the interest of making this process completely transparent, I have also created a process document outlining how we review RFCs and guidelines on how to create them going forward:
https://openmama.github.io/openmama_rfc_process.html
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
FRANK QUINN Principal Engineer, Europe
O. +44 289 568 0209 x3592
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. |
|
|
|
Frank Quinn <fquinn@...>
Good question… the approach we had planned on taking was to allow accessors to be called and return an error if an extended value was requested via a function which doesn’t support extended values.
An argument could certainly be made to implement what you’re talking about and in terms of code, it would be the easiest thing in the world to add, but I think (after some deliberation) we should avoid it because:
1. It makes the application aware of the concept of “Extended” values, which I expect the application developer won’t want to have to consider independently 2. Whether it’s extended or not is usually irrelevant until you try to read or write to it using certain accessors in which case we have a mechanism already in there in returning an error code (which applications should already be checking) 3. It would mean introducing a method which would immediately get deprecated in MAMA 7 (as we will revisit the interface at that point to make all interfaces support extended data types)
I also have one eye on trying to steer anyone who is depending on extended data types to actually move exclusively towards methods which support extended values and use POSIX mechanisms rather than have conditional statements where they need to maintain two blocks of code – one for extended and one for the old non-extended.
Cheers, Frank
From: Tom Doust [mailto:tom.doust@...]
Sent: 14 December 2016 08:56 To: Alpert, Reed <reed.alpert@...>; Frank Quinn <fquinn@...>; 'Openmama-dev@...' <Openmama-dev@...> Subject: RE: RFC for Extended MAMA Date Time
One question, (and I haven’t fully thought this through), is there any need to be able to determine at runtime, given a mamaDateTime object, whether it contains an extended value?
Tom
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Alpert, Reed via Openmama-dev
Hi,
This looks good for JPMChase, we will be able to support our securities before 1970 and far into the future.
Thanks,
Reed.
From:
openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Frank Quinn
Hi Folks,
I have just opened up a new RFC to cover the upcoming Extended MAMA Date Time functionality. You can find it listed here:
https://openmama.github.io/openmama_rfc_open.html
Also note that in the interest of making this process completely transparent, I have also created a process document outlining how we review RFCs and guidelines on how to create them going forward:
https://openmama.github.io/openmama_rfc_process.html
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
FRANK QUINN Principal Engineer, Europe
O. +44 289 568 0209 x3592
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. 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. Vela Trading Technologies LLC |
|
|
|
Tom Doust
Returning an error sounds fine to me.
From: Frank Quinn [mailto:fquinn@...]
Sent: 14 December 2016 09:24 To: Tom Doust <tom.doust@...>; Alpert, Reed <reed.alpert@...>; 'Openmama-dev@...' <Openmama-dev@...> Subject: RE: RFC for Extended MAMA Date Time
Good question… the approach we had planned on taking was to allow accessors to be called and return an error if an extended value was requested via a function which doesn’t support extended values.
An argument could certainly be made to implement what you’re talking about and in terms of code, it would be the easiest thing in the world to add, but I think (after some deliberation) we should avoid it because:
1. It makes the application aware of the concept of “Extended” values, which I expect the application developer won’t want to have to consider independently 2. Whether it’s extended or not is usually irrelevant until you try to read or write to it using certain accessors in which case we have a mechanism already in there in returning an error code (which applications should already be checking) 3. It would mean introducing a method which would immediately get deprecated in MAMA 7 (as we will revisit the interface at that point to make all interfaces support extended data types)
I also have one eye on trying to steer anyone who is depending on extended data types to actually move exclusively towards methods which support extended values and use POSIX mechanisms rather than have conditional statements where they need to maintain two blocks of code – one for extended and one for the old non-extended.
Cheers, Frank
From: Tom Doust [mailto:tom.doust@...]
One question, (and I haven’t fully thought this through), is there any need to be able to determine at runtime, given a mamaDateTime object, whether it contains an extended value?
Tom
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Alpert, Reed via Openmama-dev
Hi,
This looks good for JPMChase, we will be able to support our securities before 1970 and far into the future.
Thanks,
Reed.
From:
openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...]
On Behalf Of Frank Quinn
Hi Folks,
I have just opened up a new RFC to cover the upcoming Extended MAMA Date Time functionality. You can find it listed here:
https://openmama.github.io/openmama_rfc_open.html
Also note that in the interest of making this process completely transparent, I have also created a process document outlining how we review RFCs and guidelines on how to create them going forward:
https://openmama.github.io/openmama_rfc_process.html
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
FRANK QUINN Principal Engineer, Europe
O. +44 289 568 0209 x3592
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.
|
|
|
|
Frank Quinn <fquinn.ni@...>
Hi Folks, As there have been no changes requested for this RFC, I will now consider it closed and approved. Thank you all for your attention in reviewing this.On Wed, Dec 14, 2016 at 9:33 AM, Tom Doust <tom.doust@...> wrote:
|
|
|
|
Dmitri Fedorov <dfedorov.solace@...>
Hi Frank, can I have one more week for that please? Regards, Dmitri Fedorov Software Architect Solace Ottawa, ON Canada Solace Corporation accepts no liability for the content of this
email, or for the consequences of any actions taken on the basis of the
information provided, unless that information is subsequently confirmed in
writing. Any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Solace Corporation. On Sat, Jan 7, 2017 at 7:51 AM, Frank Quinn <fquinn.ni@...> wrote:
|
|
|
|
Frank Quinn <fquinn.ni@...>
Hi Dmitri. Honestly you should have reviewed it by now. The RFC review period is supposed to be 2 weeks and it has been almost a month now so it remains closed. In saying that if you want to suggest changes, you're free to follow https://openmama.github.io/openmama_rfc_process.html#how-to-provide-rfc-feedback and it'll be considered on a best-effort basis, but you'll need to be quick as Vela (who are completing this work) may well have started work already according to the current form of the RFC. Cheers, On Mon, 9 Jan 2017, 15:55 Dmitri Fedorov, <dfedorov.solace@...> wrote:
|
|
|
|
Dmitri Fedorov <dfedorov.solace@...>
Look good for Solace. Regards, Dmitri Fedorov Software Architect Solace Ottawa, ON Canada Solace Corporation accepts no liability for the content of this
email, or for the consequences of any actions taken on the basis of the
information provided, unless that information is subsequently confirmed in
writing. Any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Solace Corporation. On Tue, Dec 13, 2016 at 6:20 AM, Frank Quinn <fquinn@...> wrote:
|
|
|
