Re: OPRA is not FAST
Daniel May / SpryWare, LLC <>
7 Nov 2008 11:08AM ET
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);
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.