|
5.0 Feedback
< Previous Next >
Re: ApplVerID vs CstmApplVerID
Matt Simpson / Chicago Mercantile Exchange
21 Aug 2007 7:06PM ETThe original plan was to provide new enumerations for ApplVerID only as new service packs were released - not for each extension pack. Early adopters could use an EP prior to official release in an SP by referencing it in CstmApplVerID (per the value assigned by the GTC).
This has the benefit of reducing the number of "application versions" that are available. It is common for an SP to contain as many as 10-15 EP's.
The downside is that early adoptors must drop their reference to the EP in CstmApplVerID and begin using the ApplVerID enumeration which represents that SP once it is released.
We should discuss both approaches in the FIX 5.0 Usage Group.
> Ok, thanks for the pointer.
>
> However, the document doesn't seem to clearly specify whether the
> CstmApplVerID is sufficient in it self to identify a particular version
> of a message or if the domain is local to the specified ApplVerID in
> which case you'd need booth. Nevertheless, I'm reading the document to
> mean that given a particular extension pack number, the underlying
> service pack follows implicitly.
>
> This would mean that specifying the extension pack number alone is all
> you need. Which further means that the two versions could be combined
> into one identifier.
>
> The combined identifier would still be an enumeration so size wouldn't
> be a problem. Since it is GTC that assignes both service and extension
> pack numbers, the sequence could be continuous. For example
>
> 7 = FIX 5.0 8 = FIX 5.0 EP 1 9 = FIX 5.0 EP 2 10 = FIX 5.0 SP 1 //
> Includes EP 1 & 2 ...
>
> And you could allow for custom extension identifiers in an upper range
>
> 4000 = FIX 5.0 EP 2 with some extra sugar on top
>
> /David
>
Re: ApplVerID vs CstmApplVerID
Matt Simpson / Chicago Mercantile Exchange 21 Aug 2007 7:06PM ET
|
