RE: [Quickfix-developers] Re: empty tag

[Steve B. <st...@te...>]

I vote this approach as the default behavior, possibly with a
configuration option for the other behaviors.

> -----Original Message-----
> From: qui...@li... [mailto:quickfix-
> dev...@li...] On Behalf Of Brian Erst
> Sent: Tuesday, July 05, 2005 9:46 AM
> To: Oren Miller; Alvin Wang
> Cc: qui...@li...; quickfix-developers-
> ad...@li...
> Subject: Re: [Quickfix-developers] Re: empty tag
> 
> 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
> 
> Oren -
> 
> I'd definitely go with the NoTagValue exception method rather than
> attempting to guess what the developer "really" wants.
> 
> You have the removeField method for the case of needing to strip a
> field out of a message, so providing a backdoor way of doing that via
> adding a "blank" value is redundant. It also isn't obvious that "blank"
> = "delete".
> 
> Considering how many FIX engines choke on a missing tag value, I think
> it's a good idea to default to not allowing it. I'd rather add a new
> method (addBlankField or some such) or optional parameter (e.g.,
> message.set(value, allowBlanks)) on the off chance that some weird FIX
> implementation out there requires the existence of a tag even if there
> is no value for it than allow what is normally considered "bad" FIX to
> go out by default.
> 
> - Brian Erst
> Thynk Software, Inc.
> 
> --- Oren Miller <or...@qu...> wrote:
> 
> > My concern is how to handle the situation where the field already
> > exists.  If field 58 is set in the message, and I set it again with a
> > field that has an empty tag, what does this mean?  Does it mean that
> > I ignore the new field and retain the old value?  Or do I remove the
> > old field from the message completely.  In which case setting a field
> > with an empty tag is the same behavior as calling removeField.  Both
> > of these behaviors feel a little surprising to me.  I'd be interested
> > in hearing other opinions on this.
> >
> > --oren
> >   ----- Original Message -----
> >   From: Alvin Wang
> >   To: Oren Miller
> >   Cc: qui...@li... ;
> > qui...@li...
> >   Sent: Tuesday, July 05, 2005 9:40 PM
> >   Subject: [Quickfix-developers] Re: empty tag
> >
> >
> >
> >   Oren, I can understand where you are coming from. It makes total
> > sense if QF throws NoTagValue exception in this case. However, I just
> > feel it will add workload to the developers and the production may
> > become disruptive.
> >
> >   Thanks
> >   Alvin
> >
> >
> >
> >
> >        "Oren Miller" <or...@qu...>
> >         07/05/2005 10:00 AM
> >
> >
> >                 To:
> > <qui...@li...>,
> > <qui...@li...>, "Alvin Wang"
> > <AW...@FF...>
> >                 cc:
> >                 bcc:
> >                 Subject:        Re: empty tag
> >
> >
> >
> >   We could, although more likely I would throw a NoTagValue
> > exception.  I don't much like the idea of having QF silently ignoring
> > a field that the developer would be expecting to go out in the
> > message (much like I don't like the current behavior).  I can imagine
> > the head scratching that would go on if they added a field and then
> > found it mysteriously absent in the logs.
> >
> >   In either case if you have a field that might contain a blank
> > value, I would suggest checking it before adding it to a message.
> >
> >   --oren
> >   ----- Original Message -----
> >   From: Alvin Wang
> >   To: qui...@li... ;
> > qui...@li...
> >   Cc: Oren Miller
> >   Sent: Tuesday, July 05, 2005 9:10 PM
> >   Subject: empty tag
> >
> >
> >   HI
> >
> >   If I set a tag as below:
> >   message.set(new Text(text));
> >   and if the variable "text" is null. QF will include an empty tag
> > 58. As a result, some FIX engine (such as QF itself) on the other end
> > will reject the message.  Can QF skip including empty tag?
> >
> >   Thanks
> >   Alvin
> >
> **********************************************************************
> > This e-mail message is intended solely for the use of the addressee.
> > The message may contain information that is privileged and
> > confidential. Disclosure to anyone other than the intended recipient
> > is prohibited. If you are not the intended recipient, please do not
> > disseminate, distribute or copy this communication, by e-mail or
> > otherwise. Instead, please notify us immediately by return e-mail
> > (including the original message with your reply) and then delete and
> > discard all copies of the message. We have taken precautions to
> > minimize the risk of transmitting software viruses but nevertheless
> > advise you to carry out your own virus checks on any attachment to
> > this message. We accept no liability for any loss or damage caused by
> > software viruses.
> >
> **********************************************************************
> >
> >
> >
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers