[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/cc3cdf5e - PLEASE DO NOT REPLY BY MAIL.]
All, the individual extensions are very different in nature. I believe we should be careful not to include anything in the standard that we cannot demonstrate is definitely needed. As Jim commented: "when in doubt leave it out". I also think that we should follow the IETF mantra of "implementation before standardization". Preferably at least two implementations that could be compared for interoperability. I'd like to do the following grouping of the proposed features: 1.1.1 scope - Enumeration data type - Set data type - Timestamp data type 1.2 scope - Bitgroup data type 2.0 scope - Map operator - Pmap field placement The 1.1.1 scope is fairly obvious too me. It's needed for the FIX over FAST project. None of the 1.1.1 features break any existing implementation apart from the added template syntax that can be emulated with uInt fields. The 1.2 scope has limited empirical backing. Greg Maynard of the ISE has done some analysis and IIRC they would save two bytes per message in an already aggressively compressed high volume feed. I did some testing using the CME feed a while back and found that bit groups could contribute to a higher compression rate, but those tests were incomplete and would need to be rerun, possibly jointly with the CME. I'd guess that the Eurex EBS feed could benefit as well. Bitgroups can also be emulated with uInt fields. The 2.0 scope has virtually no empirical backing. - map operator This feature has been discussed on several different occasions, Kevin brought it up in conjunction with OTC instruments, a similar feature is used in one of the Xetra feeds, ... Furthermore, besides not having a solid use case, we're not in full agreement on how the map operator should be implemented. There is no convenient emulation available. - Pmap placement Dan and I did some back of the envelop calculations a few years back when we discussed the indivisibility problem with pmaps (you consume a byte as soon as you use a bit). The original idea was to use the extra bits instead of just wasting them. We also discussed the possibility to only use the pmap for one bit values, two valued fields like booleans. We should probably analyze one-bit and multi-bit scenarios separately. So, 1.1.1, 1.2, 2.0 or some variant thereof? Best, Rolf [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 -~----------~----~----~----~------~----~------~--~---
