[This message was posted by Jim Northey of The LaSalle Technology Group <[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/e2c7fa57 - PLEASE DO NOT REPLY BY MAIL.]
I agree with you Hanno in terms of complexity is a perception issue. I also agree that we should not avoid a "good" feature. However, "good" is not a sufficient adjective. I am reminded of the previous HSBC advertising campaign where the same object is viewed both negatively and positively - depending upon observer. I would prefer that we instead proactively attempt some form of decision making process where we include implementation complexity, backward compatibility, and the temporal and spacial quantitative benefits of an extension as part of the decision making process and carefully document and then test before standardizing. For instance, is there some marginal value for putting field data within the PMAP? There may be - but I would argue it is a marginal benefit when compared to the costs to existing implementations and to breaking the model of "presence" map. From a conceptual perspective, from a processing perspective - including field data in the PMAP is an unnecessary complication that needs to be analyzed against quantitative bbenefits. At this point in the life of the FAST Protocol - I think FPL should underwrite engineering exercises and testing before we break the existing protocol and risk splintering FAST into multiple dialects. I don't think the resulting fragmentation of the standard is worth this feature. The other area in terms of complexity is the scaled decimal numbers and the issue of one or two bits in the presence map - but I think this complexity has already been absorbed by the industry - trying to address this probably is not justified from a business case perspective. Other than that I believe you have identified a critical aspect of what FPL should be doing with member's funding - I think one of the key things FPL should be doing is improving the quality of education material and implementation guides to the industry. This was a major driver behind us deciding to bring on board additional full time technical resources. I agree proprietary extensions or improper implementations are more a threat than a new standardized feature (within reason of course). > 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 -~----------~----~----~----~------~----~------~--~---
