[This message was posted by Sebastien Fortas of Societe Generale <[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/4b5e5c0d - PLEASE DO NOT REPLY BY MAIL.]
> 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)? 3. 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. 4. 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 -~----------~----~----~----~------~----~------~--~---
