[This message was posted by Russell Curry of Assimilate Technology, Inc. <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/4222a0cb - PLEASE DO NOT REPLY BY MAIL.]
> The main element of the proposal is the new throttle component block > based on the need to convey throttle information on a per session > basis (or even per message type within a session). UserResponse is > just one of the messages it makes sense to add this block. The Logon > response is another but we decided to leave this out for now as it has > an impact on FIXT. This is what I think doesn't make sense - why start wedging this stuff into all of these different messages, as opposed to just giving this subsystem the recognition it deserves? I can see the need to add a specific field to messages, although even that would be better served as a priority level (e.g. Priority rather than ThrottlInst), but the actual session establishment and session control stuff, makes a lot more sense if it's isolated into a separate message. > In general, I believe that less messages flowing back and forth is > better and do not think that dedicated messages for throttling are > warranted. But creating dedicated messages is exactly what this proposal does - it's just that the dedicated messages are being created by tightly binding the throttling details to some messages that don't appear to be designed for that purpose... > The UserXXX messages are generic in my view and should be > used to inform the user about various things after the initial logon > was successful. I do not think we should restrict these messages to a > narrow scope. The UserXXX messages cease being generic as soon as you start binding specific throttling fields to them, right? I could be mistaken, but when I looked at the proposal it seemed like the throttling fields would become full-fledged member fields of those messages, not data that was carried in their generic payload sections. Essentially, by not segregating this stuff, at the very least into the payload blocks of the UserX messages, you end up throwing conceptual integrity out the window for all of those messages, and you end up with a more convoluted software architecture to deal with the messages - it would be pretty easy to add QoS handling to a system with new messages, but if you start hacking this into the old stuff, people have to go back into all of their code and start hacking too... [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.
