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

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

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
> > _______________________________________________
> > Quickfix-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-users
> > 
> 
>