[This message was posted by Ravi Ravisankar of IBM <[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/1fe07879 - PLEASE DO NOT REPLY BY MAIL.]
Rolf, We decided to have a common decoder for all the FAST feeds. Since OPRA FAST implementation is non-standard, it posed challenges in the following area: 1. Lack of templates for messages. OPRA defines FAST fields and messages in header files. We generated templates for OPRA messages from the header files, so that the common decoder could consume it. 2. The presence offset for a field in the PMAP is static and based on field id. This is a deviation from FAST specification, but can be handled in the decoder logic. (Adds a cmp and jmp instructions in the presence bit lookup, not very bad!) 3. Messages k and Y (OPRA actually discontinued this message now) needs special processing. Both include/exclude some fields conditionally, based on runtime value of another field. > Ravi, > > thank you for your comments. Would it be possible for you to share some > thoughts regarding the OPRA impl? What did you do to efficiently support > the non-std aspects of OPRA? > > Best, Rolf > > > > We have implemented the full FAST specification 1.1 in 4 weeks. We > > wrote decoder and xml parser in C. The specification is short and > > crisp. The examples are very useful and we implemented them as unit > > tests. We are using the decoder for several feeds including OPRA. > > > > > What can I say except yes - it it clearly way too complicated. Given > > > it ignores one bit which is potenitally 20% of capacity I can't even > > > see that it is ultra compact. But anyway we have gone from a hugley > > > verbose but easy to use format to a very compressed and ultra > > > difficult format. I think best to junk it and start again! At the > > > very least give up on new versions until the documents are perfect > > > and the sample application are usable. The only ones who are going > > > to profit from all of this is the software vendors selling fast fix > > > convertors. But sending data should not be that difficult. Anyone > > > who says this stuff is not difficult tell me how many lines of code > > > for a complete project... I am still writing and looks like months > > > of work... [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 -~----------~----~----~----~------~----~------~--~---
