[This message was posted by Glenn McClements of <[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/a22f00af - PLEASE DO NOT REPLY BY MAIL.]
Compared to ASCII FIX, TLV message formats FAST *is* complex. My view is that FAST was designed to solve a problem of bandwidth problem and it does that extremely well by using every trick in the book (for want of a better phrase). However this does make it a lot more complex than non-compressed self describing message structures. Ideally FAST should become a commodity and one and an official fully implemented reference implementation would go some way to achieving that. People will always be able to differentiate their implementations on performance. The proposed extensions look good to me, and plug some of the gaps to making FAST a generic message format. Glenn > The perception of complexity often comes from a lack of knowledge. > Separate from the spec, a good set of usage guidelines and examples > would help to understand the concepts. Some of the existing > implementations have such examples in their docs which could be > pulled together. > > Guidelines need to cover the encoding aspects (e.g. how does a FAST > message actually look like?) as well as best practices for template > design (e.g. how do I decide which operator to use?). > > FAST should become a commodity service for those that have to deal with > the application level. The role of the database application programmer > is different from a physical database designer who has to worry about > primary keys, partitions etc. People that deal with the low level, more > technical stuff will not mind the complexity as it is the only way to > increase speed. Maybe the problem is simply that the wrong skill profile > is trying to tackle FAST. Designing a FIX message and designing a FAST > template for it are quite different things. The FAST guy does not really > need to have any idea of what the underlying business functionality is. > He needs information about the repetitive nature of the data, i.e. how > does the data change from one message to the next and how often does > which piece of data occur. > > My view about extensions is that we should not avoid a good extension > just because we cannot ensure that everybody implements it. People will > implement what they want/need to use. Vendor solutions should be > complete similar to a FIX engine. I am more worried about proprietary > extensions that are not part of the standard. People will want to > achieve further optimization and they need a way to do that within the > standard. A new version 1.2 capturing those extensions is the right way > forward I believe. > > Regards, Hanno. [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 -~----------~----~----~----~------~----~------~--~---
