[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/cc4bc579 - PLEASE DO NOT REPLY BY MAIL.]
I strongly agree with you on this Hanno 1. The presence map then is no longer a presence map - a fundamental recoding of most existing applications will have to occur. 2. Usage of this feature is clearly is not backwardly compatible to previous implementations of FAST. 3. There are no proven temporal or spatial quantitative benefits demonstrated. 4. Breaking the abstraction of Presence Map and making it Presence Map with data sometimes being present is a major conceptual change and will lead to increased test cases to validate an implementation. I think we should also take a more conservative stance in terms of protecting the existing install base. We should say prove why this feature should be in place - FIX is probably one of the most accomodating standards organizations in existence - we often say "you want something in the protocol we will add it" - and this is an important part of our success - but it is also part of our undoing - with something as non-trivial (I did not say complex) as FAST and with the number of installations now in existence - I think we have to put up a larger firewall and require those proposing "good" features to prove both their business and technical cases before standardizing. I would also like to paraphrase something Rolf said on yesterday's call in American Colloquial as "when in doubt leave it out". We can always standardize a contentious feature in the future. Removing a feature once standardized is a near impossibility. If we can't come to consensus - the feature should not be codified as part of the standard. > My view on this one is that we should give the clear design priority at > this stage and keep the pmap restricted to metadata. It appears to me to > be more of an extension for a FAST 2.0, whatever that may be. There are > still implementations out there struggling with FAST 1.1 compliance. I > think it is better to let the implementations become more mature and the > number of FAST experts grow before optimizing data into the pmap. The > bitgroup extension is more significant and already helps a lot with the > fields having a very small range of values. > > Regards, Hanno. > > > All, > > > > following up on today's call; > > > > a few people on the call today voiced concerns about the added > > complexity of FAST as a consequence of the pmap field placement > > proposal. > > > > If I understood the comments correctly, the mix of metadata and data > > would be problematic in some of the current implementations. > > > > I'd like to get your comments on this as well as suggestions on how we > > should go forward. > > > > 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 -~----------~----~----~----~------~----~------~--~---
