Re: FAST Complaints
Dale Wilson / Object Computing, Inc
3 Feb 2010 2:01PM ET
> > But Rolf, an example, please define the semantics of an "empty"
> > integer and add the reason why you would even consider adding
> > all three : a PMAP, template instance and optional attribute
> > on top of it? Plus you make it nullable and optional and empty
> > and pmap dependent and hey dynamically imposable.
> Is this a trick question or are you just trying to be funny at my expense?
> I don't understand what you want to say. You loose me halfway through the
> first sentence (at the "and"). I'll take these five lines apart when I get
> some more time. If I find a plausible interpretation, I will certainly post.
> In the meantime, I would appreciate if you re-read your own text and if
> possible try to explain what you are getting at here. Your own
> deconstruction if the 5 lines may be helpful.
On the assumption that a clearer explanation is not likely to be forthcoming I'd like to discuss this issue.
The original poster apparently doesn't understand the difference between sending the value of a field on the wire and including the field in the application message that is generated as a result of decoding a FAST message -- or more likely he doesn't think this distinction is important. I'm guessing that he would prefer to use a "null value" in the application message generated by the decoding process rather than omitting the entry altogether. Several protocols take this approach including Ouch/Itch, and the original ARCA market data protocol.
The use of "magic numbers" is a technique commonly used by inexperienced programmers. It can also be used by experienced programmers in very specific cases where a null value is readily available. It is not suitable for use in a general-use protocol because there are many circumstances in which no convenient null value exists.
If you consider FAST as a general purpose protocol that avoids imposing arbitrary restrictions on the data being transmitted, then using a null value in the application data is inappropriate. If you consider FAST as a limited-purpose protocol intended to address just one application domain -- the distribution of market data -- then it might make sense to impose artificial restrictions on the type of data that can be transmitted. This in turn could simplify the protocol making it more understandable to inexperienced programmers.
I believe that is what the original poster is advocating: simplicity over completeness.
This simplification of the protocol would not necessarily simplify the code necessary to encode/decode and process messages because at some point the "missing" data would have to be detected and handled.
As an aside, it is interesting that the original post mentioned SOAP as a failing, complex protocol. SOAP (the 'S' at one point stood for for "Simple") was originally proposed as an alternative to more complete and hence more complex protocols like CORBA. It was only when SOAP encountered "real-world" problems that it slowly evolved into a more complete system that rivals or exceeds CORBA in complexity without even coming close to matching it in efficiency. The moral is beware of simplistic solutions to inherently complex problems (and vice versa.)
In this attempt to make sense and salvage something useful from the original post, I have read into his statement quite a bit of meaning that isn't expressed by the original post. It might also be worthwhile to take the original at face value. It may be that he truly doesn't grasp that the PMAP and the presence="optional" attribute address different issues.
This misunderstanding may be a symptom of a weakness in the description of the protocol: the overloading of the word "presence." The specification would be easier to understand if a separate word had been used to express the condition that the field is not required in the application data. This is something that could be addressed in FAST 1.2 (or beyond) by renaming the presence="" attribute to avoid confusion between it and the "presence map."
For example, if this attribute of a field instruction were specified in the XML file as required="no" it might reduce the potential for confusion. Once again, however, this is a cosmetic issue that doesn't affect the underlying value of the protocol.
It is also worth noting that the meaning of a presence map bit is not completely consistent. In all but one case the presence map bit specifies whether there is any data on the wire for this particular field. In these cases the presence map bit bears no relationship to the presence or absence of the field in the application message.
The exception is for the constant operator. For this operator the data is NEVER sent down the wire, and the presence map bit for this one case indicates whether the field is included in the application data. This overloading of the meaning of the presence map bit, while certainly understandable, may also be a source of the original poster's confusion.
Dale
--
Principal Software Engineer, Object Computing, Inc.
www.ociweb.com
Lead developer of the QuickFAST open source
implementation of the FAST protocol.
www.quickfast.org
