|
4.1 Changes
< Previous Next >
re: ID Changes
Mark Hinman
5 Feb 1998 1:29PM ETThe problem with with changing the data types instead of creating a new data fields is maintaining multiple simultaneous FIX connections across different versions of the spec. Global search and replace sounds easy but it kill backwards compatiblity with other FIX connections. We currently are supporting concurrent connections to FIX 2.7, 3.0 and 4.0. and we intend to continue full backwards compatiblity.
Mark Hinman
Ease Technologies, Inc.
mhinman@easetech.com
> 4.1 Version Changes ID's
>
> Our implimentation will require less work to change the id data types to char than to add the extra code to handle the new ids to the many apps that use the engine.
>
> Is this the case with others implimentations?
>
> If this is so maybe its easier all round to just change the data type. For instance with IOIs we have a program that displays these and keys not unsprisingly on IOIId. It assumes this is unique but that is all. To change the engine so that we potentailly put blanks in IOIId and have to put the IOIId into IOICharId means we have to change the next level of our architecture. Each step up we propogate out the changes forces more work for the people who build system based on FIX.
>
> Plus this will be confusing and we will inevitably get people wrongly using the Id that remain present but not supported. These systems will then break when the unsupported parts of implimentation are not longer generated. This sort of soft compatablility is very nasty.
>
> NB Some vendors already use char for all ids so we've already made changes to accomodate this in the past. These vendors would then have no changes to make.
>
> In summary, we are concerned about repeating information in two different, and one redundant, formats. This will inevitablely lead to confusion.
>
> Andrew Wilson
> Andrew.A.Wilson@flemings.com
>
re: ID Changes
Mark Hinman 5 Feb 1998 1:29PM ET
|
