[This message was posted by Rich Shriver of Jordan & Jordan <[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/76ada910 - 
PLEASE DO NOT REPLY BY MAIL.]

I think we should remember that these extensions were primarily identified as a 
result of discussions that came from the work we have been doing for FIX over 
FAST and from other implementers of FAST that have asked for specific 
incremental improvements.  There are some features which I beleive are very 
important to the efficiency of FIX over FAST,  Perhaps this has been lost to 
some extent as we focus in on the concise details.

In one specific instance, a FAST implementer asked for a solution where a pmap 
bit could be used to represent one of two possible values for a field instead 
of burning up a pmap slot and a field.  Thus the onset of mixing data within 
the metadata in the pmpap begins.  I don't believe this is a new concept and 
the logical extension is to provide a greater capability than inlining a single 
pmap bit for data.

[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
-~----------~----~----~----~------~----~------~--~---

Reply via email to