Thread: [Quickfix-developers] Re: empty tag
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Alvin W. <AW...@FF...> - 2005-07-05 14:07:25
|
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.
**********************************************************************
|
|
From: Oren M. <or...@qu...> - 2005-07-05 14:17:44
|
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 -----=20
From: Alvin Wang=20
To: Oren Miller=20
Cc: qui...@li... ; =
qui...@li...=20
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.=20
Thanks=20
Alvin=20
"Oren Miller" <or...@qu...>=20
07/05/2005 10:00 AM=20
=20
To: <qui...@li...>, =
<qui...@li...>, "Alvin Wang" =
<AW...@FF...>=20
cc: =20
bcc: =20
Subject: Re: empty tag=20
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.=20
=20
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.=20
=20
--oren=20
----- Original Message -----=20
From: Alvin Wang=20
To: qui...@li... ; =
qui...@li...=20
Cc: Oren Miller=20
Sent: Tuesday, July 05, 2005 9:10 PM=20
Subject: empty tag=20
HI=20
If I set a tag as below:=20
message.set(new Text(text));=20
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?=20
Thanks=20
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. =
**********************************************************************=20
|
|
From: VP M. IT A. E. T. <ass...@gm...> - 2005-07-05 14:42:17
|
My opinion and what I would find useful:
if (tag already set)
{
replace old value if a new non empty value is present
never allow duplicate tags in the msg
}
Instead of numerous QF users to be checking and setting..it is better
to factor this in QF.
the issue of ambiguity may be resolved whenever
QF rejects a tag/value set operation by logging=20
"QFEONP QF Error Op Not Performed...tag without value cannot be added"
"QFEONP QF Error Op Not Performed...tag cannot be added for this msg"
"QFEONP QF Error Op Not Performed...tag value cannot be added in the
given format"
to a special QFE.log file
On 7/5/05, Oren Miller <or...@qu...> wrote:
> My concern is how to handle the situation where the field already exists.=
=20
> If field 58 is set in the message, and I set it again with a field that h=
as
> an empty tag, what does this mean? Does it mean that I ignore the new fi=
eld
> 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.
> =20
> --oren
> ----- Original Message -----=20
> From: Alvin Wang=20
> To: Oren Miller=20
> Cc: qui...@li... ;
> qui...@li...=20
> Sent: Tuesday, July 05, 2005 9:40 PM
> Subject: [Quickfix-developers] Re: empty tag
>=20
>=20
> 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 ad=
d
> workload to the developers and the production may become disruptive.=20
>=20
> Thanks=20
> Alvin=20
>=20
>=20
>=20
>=20
> "Oren Miller" <or...@qu...>=20
>=20
> 07/05/2005 10:00 AM=20
> =20
> To: =20
> <qui...@li...>,
> <qui...@li...>, "Alvin
> Wang" <AW...@FF...>=20
> cc: =20
> bcc: =20
> Subject: Re: empty tag
>=20
>=20
> 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 log=
s.=20
> =20
> In either case if you have a field that might contain a blank value, I wo=
uld
> suggest checking it before adding it to a message.=20
> =20
> --oren=20
> ----- Original Message -----=20
> From: Alvin Wang=20
> To: qui...@li... ;
> qui...@li...=20
> Cc: Oren Miller=20
> Sent: Tuesday, July 05, 2005 9:10 PM=20
> Subject: empty tag=20
>=20
>=20
> HI=20
>=20
> If I set a tag as below:=20
> message.set(new Text(text));=20
> 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?=20
>=20
> Thanks=20
> 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 u=
s
> immediately by return e-mail (including the original message with your
> reply) and then delete and discard all copies of the message. We have tak=
en
> precautions to minimize the risk of transmitting software viruses but
> nevertheless advise you to carry out your own virus checks on any attachm=
ent
> to this message. We accept no liability for any loss or damage caused by
> software viruses.
> **********************************************************************
>=20
>
|
|
From: Brian E. <azz...@ya...> - 2005-07-05 14:46:33
|
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. > ********************************************************************** > > > |
|
From: Steve B. <st...@te...> - 2005-07-05 15:31:23
|
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 |
|
From: Joerg T. <Joe...@ma...> - 2005-07-08 14:38:26
|
Steve Bate wrote: > I vote this approach as the default behavior, possibly with a > configuration option for the other behaviors. So do I. NoTagValue exception is the best way to handle. An optional parameter to the set() method sounds like a good idea. Cheers, Jörg >>-----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 -- Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen |
|
From: Steve B. <st...@te...> - 2005-07-08 16:24:40
|
Hi, Is it intentional that the MsgType field doesn't have field values specified in the DD XML? I'm working on a tool where I'd like to display user-friendly names for the MsgType as I noticed there's no field values for that field. Steve |
|
From: Oren M. <or...@qu...> - 2005-07-12 16:16:59
|
It looks like FIX43.xml and FIX44.xml do have them, so I don't see a problem with adding them to the earlier versions. You can however always get those names from the Message element regardless. --oren ----- Original Message ----- From: "Steve Bate" <st...@te...> To: <qui...@li...> Sent: Friday, July 08, 2005 11:26 AM Subject: [Quickfix-developers] MsgType field values in DD XML? > 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 > > Hi, > > Is it intentional that the MsgType field doesn't > have field values specified in the DD XML? I'm working on a > tool where I'd like to display user-friendly names for the > MsgType as I noticed there's no field values for that field. > > Steve > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted by > HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
