[This message was posted by Rich Shriver of Jordan & Jordan <[EMAIL PROTECTED]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/f814d38e - PLEASE DO NOT REPLY BY MAIL.]
FPL and members of MDOWG provided feedback to SIAC that the OPRA FAST implementation was non-compliant with the FAST specifications. The feedback has yet to be incorporated or addressed. What has not occured is pressure from OPRA direct feed customers to make the technology compliant with the standards. As a standards organization, we have also not effectively lobbied OPRA and their technology service provider to comply with the standards as developed. I am not saying we have not lobbied, I am simply stating we have yet to be successful. Rich Shriver > Jim, This has been a long standing issue with OPRA that seems to have > fallen on deaf ears. It all started when OPRA simply used the proof on > concept code that SpryWare and Pantor wrote to demonstrate the concept > of FAST and released it as a production feed. They never consulted the > group to review their implementation, in fact they distributed decoder > source coded that still contained the original proof of concept cvs > version control headers. > > The proof of concept code was not FAST compliant, because FAST was not > even formalized at that point. I do believe they consulted Jordan and > Jordan before releasing their version 2 of OPRA FAST, "OPRA FAST for > Symbology", about correcting the non compliant portions of the code. For > some reason they chose not to bother. > > So you are left with a feed that cannot be decoded with a generic FAST > decoder. The changes are minor, simply adding a few more templates > rather than having messages templates dynamically changed based on > message content. > > /Daniel > > > > OPRA is not a FAST compliant market data feed - it is FAST-like but is > > not compliant with the FAST Specification. What are other vendors > > doing to address the OPRA Market data feed - which should not be > > confused with being a FAST market data feed? We are a bit concerned to > > alter or break our standard implementations to support OPRA. Seems > > like an alternative product or code branch might be preferred to > > corrupting the main code line of a FAST compliant product. [You can unsubscribe from this discussion group by sending a message to mailto:[EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
