Re: [Quickfix-users] Modifying toAdmin/toApp messages

[Brian E. <azz...@ya...>]

Following up my own message, for complete backward compatibility, you'd
need a new "crack" method for the non-const methods, otherwise calling
the "new" crack() would still route messages to the "wrong" methods for
existing applications.

- Brian Erst

--- Brian Erst <azz...@ya...> wrote:

> Oren -
> 
> I think that sounds great. My main concern was whether non-C++
> platforms (.Net, Java and Python) handled overloaded methods that
> differed only by the "constness" of one of the arguments.
> 
> I also wondered about backward compatibility - if the new method
> differed only by signature, it might break existing applications
> which
> are currently using the cracker on toApp/toAdmin messages and
> performing the cast. (If you called the new cracker from
> toApp/toAdmin,
> it would crack to the non-const method, but the existing application
> would be overriding the const method, causing the messages to be
> skipped.)
> 
> A best of both worlds approach might be to simply make the
> "non-const"
> versions have a different method name (as in decorateMessage() or
> something that better fits your naming scheme) - existing
> applications
> would not be affected, but you wouldn't pollute the namespace with
> another class definition.
> 
> If/when this gets implemented, I'll try to update the Wiki to
> document
> the new behavior.
> 
> Thanks, Oren!
> 
> - Brian Erst
> 
> 
> --- Oren Miller <or...@qu...> wrote:
> 
> > No need to go typing all that up.  We certainly didn't type up the 
> > MessageCracker.  It is being generated off of the XML.
> > 
> > I think instead of creating a new Decorator class, we can add
> methods
> > that 
> > receive non-const messages alongside the const ones.  This way the
> > same 
> > message cracker can be used and C++ will be able to resolve which
> > method to 
> > call based on the constness of the message.  So for instance we
> could
> > have:
> > 
> > virtual void onMessage( const SessionID& sessionID, const 
> > FIX42::NewOrderSingle& message )
> > virtual void onMessage( const SessionID& sessionID,
> > FIX42::NewOrderSingle& 
> > message )
> > 
> > Both generated for the MessageCracker.  What do you think of that?
> > 
> > --oren
> > 
> > ----- Original Message ----- 
> > From: "Brian Erst" <azz...@ya...>
> > To: <qui...@li...>
> > Sent: Thursday, December 30, 2004 11:13 PM
> > Subject: [Quickfix-users] Modifying toAdmin/toApp messages
> > 
> > 
> > > QuickFIX Documentation: 
> > > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > > QuickFIX FAQ:
> > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > > QuickFIX Support: http://www.quickfixengine.org/services.html
> > >
> > > As I am relatively new to QuickFIX, this may have already been
> > covered
> > > in the past (I did a search across the mailing list archive and
> > didn't
> > > see much on it though).
> > >
> > > It seems to me that the use of toApp and toAdmin needs to be
> better
> > > documented and that there might be a need for a message cracker
> > > specific to these messages. None of the examples, for instance,
> > make
> > > use of either of these methods (except for a token check of the
> > > PossDupFlag in TradeClient).
> > >
> > > The FIX server I was connecting to required the use of the
> Username
> > and
> > > Password fields in a Logon message. It took a long time perusing
> > the
> > > mailing list and reading the source code to figure out that I'd
> > need to
> > > use the toApp method to trap the automatically generated Logon
> > message
> > > and modify that message.
> > >
> > > After that, I bumped into a slight problem with message cracking.
> > The
> > > MessageCracker class can crack any message, but will only
> dispatch
> > > those messages as "const", which requires a cast in order to add
> > the
> > > appropriate fields (I created a non-const pointer to the Logon
> > message
> > > and set the fields).
> > >
> > > Is there/should there be an "inbound" message cracker and an
> > "outbound"
> > > message cracker? "Inbound" messages would have a "const" modifier
> > to
> > > prevent changes to the message, while "outbound" messages would
> be
> > > non-const so the message could be modified (or "decorated") prior
> > to
> > > being sent.
> > >
> > > For backward compatibility, the "inbound" message cracker could
> > > continue to be MessageCracker, while a new class could handle the
> > > "outbound"  message cracking/decorating.
> > >
> > > I'd foresee something like:
> > >
> > > class MessageDecorator
> > > {
> > > public:
> > >
> > >    virtual ~MessageDecorator() {}
> > >    virtual void decorateMessage(Message&, const FIX::SessionID&)
> > >        {throw FIX::UnsupportedMessageType();}
> > >    virtual void decorateMessage(Heartbeat&, const
> FIX::SessionID&)
> > {}
> > >    virtual void decorateMessage(Logon &, const FIX::SessionID&)
> {}
> > >    ...
> > >
> > > public:
> > >
> > >    void decorate(Message & message, const FIX::SessionID &
> > sessionID)
> > >    {
> > >        FIX::MsgType msgType;
> > >        message.getHeader().getField(msgType);
> > >        std::string msgTypeValue = msgType.getValue();
> > >
> > >        if (msgTypeValue == "0")
> > >            decorateMessage((Heartbeat&)message, sessionID);
> > >        else
> > >        if (msgTypeValue == "A")
> > >            decorateMessage((Logon&)message, sessionID);
> > >        ...
> > >    }
> > > }
> > >
> > > and Application could inherit from both MessageCracker and
> > > MessageDecorator.
> > >
> > > Then, when an Application-derived class needs to add fields to
> > outbound
> > > messages, they simply override the toApp() or toAdmin() methods
> and
> > > override the appropriate decorator.
> > >
> > > Maybe this is overkill to avoid casting, but it also helps to
> > separate
> > > the message flow - otherwise, a single "onMessage" method might
> be
> > > called by both inbound messages AND outbound messages (when
> systems
> > are
> > > closer to being peers, you can often see the same messages going
> > both
> > > ways) and you have to add additional checks (who does the
> > SenderCompID
> > > point to in this message).
> > >
> > > Just an idea. I'm willing to put my money where my mouth is an
> > write a
> > > C++ MessageDecorator class - it's a pretty simple modification of
> > the
> > > existing MessageCracker class(es).
> > >
> > > I'll also look into updating the Wiki to document how things work
> > now -
> > > assuming I accurately understand the process.
> > >
> > > - Brian Erst
> > >
> > > p.s. QuickFIX is a very impressive piece of work - none of the
> > above
> > > should be construed as anything other than a wishlist item.
> > >
> > >
> > > -------------------------------------------------------
> > > The SF.Net email is sponsored by: Beat the post-holiday blues
> > > Get a FREE limited edition SourceForge.net t-shirt from
> ThinkGeek.
> > > It's fun and FREE -- well,
> > almost....http://www.thinkgeek.com/sfshirt
> > > _______________________________________________
> 
=== message truncated ===