[This message was posted by Michael Wynne of Michael Wynne & Co <[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/21171d10 - PLEASE DO NOT REPLY BY MAIL.]
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. > > All joking aside, I'd like to get your help. > > Hello, > > Thanks for the opportunity to speak up. I think FAST is complex but > manageable, and a good piece of work. I largely agreed with Daniel May's > comments regarding the complexity of CME's implementation of FAST, and > found other market implementations to be easier to integrate. That said, > we did have a few obstacles with the protocol implementation which I > would label as responsible for my judgement of complexity: > > 1. There are too many possible states for individual fields. I > understand the utility of being able to suppress a field from the > stream, but once you add previous value dictionary management, there > are 4 possible states for a field: undefined, absent, null, and > assigned not null. Why not two states: assigned and null? > > 2. Related to the first point: The PMAP and nullability rules (section > 10.5.1) are convoluted and do not confer discernable benefits. Why was > it necessary to specify that some fields require a PMAP bit while others > don't? This decision requires adding a great deal of logic to decoder > implementations. Would it not be simpler to specify, for instance, that > every field has a PMAP bit, that a true signals the presence of a field, > while a false signals that it is null (somewhat as it is done on OPRA)? > > 2. Some data types are redundant. The string, byte vector, and proposed > bit vector datatypes, for instance, could all be represented as byte > vectors with little difference to the stream size and no additional > logic. Similarly, group fields could be represented by sequence > fields with lengths of 0 or 1. > > 3. Like everyone, I was surprised by the lack of a functionning > reference implementation. When trying to determine why our decoder > was rejecting certain messages, we had no choice but to decode the > messages by hand - which I considered a Sisyphean ordeal - until we > got the rules for PMAP/nullability/default operators/decimal > fields/etc... right. > > A lot of these comments may have been discussed during FAST's design, so > I'm not sure if I'm restating ideas. Eventually, we got through all of > it with just the FAST specification document and this discussion forum - > so perhaps my thoughts are mere dreary memories of hard work gone by. > > Happy holidays, > > - Sebastien [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 -~----------~----~----~----~------~----~------~--~---
