[This message was posted by Hanno Klein of Deutsche Börse Systems <[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/01af919a - PLEASE DO NOT REPLY BY MAIL.]
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. > All, > > following up on today's call; > > An important point that was raised by Jim was the fact that FAST is > already perceived as "too complex" and the added complexity that follows > from the 1.2 extension proposals threaten to fragment FAST > implementations and users. > > My view is that FAST is simple, but as they say: "Beauty is in the eye > of the beholder" ... > > All joking aside, I'd like to get your help. > > In general; > - What do we need to do to assist in understanding FAST? > - Do we need a 1.1/1.2 impl that demonstrates the full feature set? > > About the 1.2 proposal; > - Should we skip one or more of the proposed extensions? > - Should we modify one or more of them? > - Should we add some other extension? > > > Thx, 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 -~----------~----~----~----~------~----~------~--~---
