|
4.0 Session
< Previous Next >
re: [PC20020211_1] Modification of encoding of binary fields
Ajay Kamdar / Javelin Technologies
26 Mar 2003 7:23AM ET I think backward compatibility with FIX engines currently in production is highly desirable.
Since almost no one can really afford to discontinue trading with a counter party just because that counter party is slow to upgrade their FIX engine, I believe as an engine vendor our customers will expect us to maintain backward compatibility with the current raw data encoding format regardless of whether the standard eventually mandates it or not.
--
Ajay Kamdar
Javelin Technologies
akamdar@javtech.co
> I think this is a good proposal:
> 1. The protocol would be more robust.
> 2. The data dictionary would be simpler.
> 3. The FIX engine implementation would be simpler.
> 4. Slightly fewer bytes would be transmitted.
>
> Only disadvantage:
> Not backwards-compatible with existing FIX engines.
>
> It would be very friendly to permit both the proposed and existing formats of encoding data fields. As a result, older FIX engines wouldn't be rendered obsolete.
>
> Does anyone have any suggestions/comments as to whether it is possible/feasable/desirable to support backwards compatability?
>
> Then again, many of us make a living out of building FIX engines. Maybe I should just be quiet and strongly support a non-backwards-compatible change ;-)
>
re: [PC20020211_1] Modification of encoding of binary fields
Ajay Kamdar / Javelin Technologies 26 Mar 2003 7:23AM ET
|
@FIXProtocol
