[This message was posted by Daniel May of SpryWare, LLC <[EMAIL PROTECTED]> to
the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You
can reply to it on-line at http://fixprotocol.org/discuss/read/0d813159 -
PLEASE DO NOT REPLY BY MAIL.]
Oleg,
As far as I can recall, there are several points where the feed is not
FAST compliant.
1. It includes a proprietary header and I believe a footer on each message.
This would not be the end of the world if the payload was actually compliant.
2. The biggest issue is the Quote template. The quote template definition is
not constant, it is defined after you process the BBO appendage fid, and based
on the value, you can then determine the number of fields that follow. This
could be solved by having a template ID for each possible BBO appendage.
This one was my own creation in the early FAST proof of concept days, that is
how I coded it to show haw FAST could work on Opra data. It made sense at the
time, but that was before FAST was formalized.
Look at the supplied fast_decode.c from Opra, and search for:
//decode bbo indicator
msg->bboIndicator = fast->decode_u32(fast, BBO_INDICATOR);
switch(msg->bboIndicator)
{
This explains it all (if you read 'C' code). The value of BBO_INDICATOR
determines the number and type of fields that follow, this is not FAST
compliant.
I do believe Rolf and some other members of the group are performing a more
complete survey of the Opra implementation.
/Daniel
[You can unsubscribe from this discussion group by sending a message to
mailto:[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Financial Information eXchange" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/FIX-Protocol?hl=en
-~----------~----~----~----~------~----~------~--~---
