[This message was posted by Rolf Andersson of Pantor Engineering <[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/80945e3f - PLEASE DO NOT REPLY BY MAIL.]
Sebastien, thank you you for taking the time to comment in detail. We are well aware of the shortcomings of the current docs. I find your observations about feature overlap and redundancy interesting. While we will most probably not remove any features, we may use these observations in our continued documentation work. Out of curiosity, which FAST feed did you implement when you first started to develop your decoder? Best, Rolf > 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 -~----------~----~----~----~------~----~------~--~---
