[This message was posted by David Rosenborg of Pantor Engineering AB <[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/e9aca799 - PLEASE DO NOT REPLY BY MAIL.]
Michael - Interoperability has been a very important objective when writing the specification. Ironically I think that the efforts made to make sure there are no ambiguities also makes it a bit harder to read. This has been an intentional trade off. The missing piece in this regard is a less formally held tutorial which still remains to be written. If you've found ambiguities in the specification, I'd be glad if you can share the specifics of those so that we can fix them in the next revision. I don't think a reference implementation is what's needed. If you're looking for source code, there are already open source alternatives to look at. What I believe is missing is * a good tutorial with detailed and illustrative examples, * test suits so you can verify the correctness of your implementation * large volume realistic trading data for performance tuning and benchmarks /David > I agree. FAST is too complex and getting worse. Having a PMAP where a 1 > bit signifies a field and a 0 signifies the absence of a field is how it > should be. It makes the decoder very very simple to code and the > implementation very fast as well. ARCA, OPRA, and other exchanges > implement this and the decoders are a few hundred lines. Implementing > CME is just a pain in the arse. Oh goody, lets use every possible > feature there is and blow the consequences. > > FAST is in danger of going the way FIX did. The protocol is just getting > feature bloat and making it harder and more complex to understand and > implement. Hence there are very very few commercial implementations that > will work off the shelf with exchange feeds. > > The protocol specification with regard to NULL fields etc is complex and > confusing and I bet if I asked 10 people I would get at least 3 > differnet explanations. > > There isnt a good clean reference implementation of the protocol and > this is a huge stumbling block as there is nowhere to go for a reference > answer to a query. > > IMHO the quality of a protocol specification can be determined from how > many questions people ask about it ?., the fewer the questions the less > ambiguous the specification is. You only have to look in these forums to > see the number and variety of problems. If you can write a spec, send it > to a developer in Australia and he/she can decode your data without > needing to contact you for clarification, then the specification is very > high quality. > > It's very hard to "undo" features once released into the wild so I would > ask that FAST be kept as simple as possible before it just loses it's > direction. > > Patrick Vickers has now released a proposal for FASTlite because of the > very problems FAST is having. It may be worth looking at. [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 -~----------~----~----~----~------~----~------~--~---
