Imported from previous forum
Between the FAST spec and the SCP spec we have two ways of representing a template. The FAST spec defines an XML schema; the SCP spec defines a special FAST-encoded method. For the most common uses of FAST, the benefits of the special encoding do not outweigh the complexity it introduces.
The SCP spec could easily define a template definition message where the template contents are transmitted as XML embedded in a unicode string field.
The cost of exchanging templates via XML is size: no doubt the special encoding will take up less space. In the typical case, template exchange is going to be a one-time cost incurred when the connection is established. Using the special encoding to save bytes then is a misplaced optimization.
On the other hand, exchanging templates via XML can simplify both the specification and the implementations built around it. Since the FAST spec defines the schema, most implementations will already be parsing it, so why not reuse that code?
Additionally, the special encoding is less expressive than the XML encoding. For example, there is no room in the special encoding for the “foreign elements” that are used to represent a template’s reset property, which is why it gets a distinct field in the special encoding. A later version of SCP will have difficulty introducing changes to the format in a simple way.
I am aware of some scenarios where one might want to transmit templates more frequently, in which case the special encoding would make more sense, but at this point it seems premature to cater to least common settings. It would not be unreasonable to define an alternate encoding in a later version of SCP, when we have a need for a compressed template representation. Until then, the special encoding is complicating the SCP specification, which in turn complicates implementations, which keeps it out of the market.
Between the FAST spec and the SCP spec we have two ways of
representing a template.
The FAST spec defines an XML schema;
the SCP spec defines a special FAST-encoded method.
For the most common uses of FAST, the benefits of the special
encoding do not outweigh the complexity it introduces.
An alternative view is that the XML representation adds to the
complexity of the runtime implementation. It is possible to do
without an XML parser given that pre-loaded templates are FAST
encoded.
It wouldn’t work the other way.
A FAST decoder is required to decode normal FAST messages.
/Rolf
The “most common uses of FAST” and “the typical case” will vary both in time and perspective.
The specific purpose of the SCP way is to exchange templates when XML doesn’t match your case and when you want to stay fully within the FAST encoding. The reasons for this may vary, it can be size, it can be execution path within you application, it can be latency and so on. If your particular application is happy with XML, just stay with it.
What specific parts of the template encoding in SCP do you find too complex? Please let me know and I’ll try to explain. Your input will help improve the specification.
BTW, support for foreign components are in the upcoming draft (and are present in the SCP Example kit that has been distributed in the working group)
/David
Between the FAST spec and the SCP spec we have two ways of representing
a template. The FAST spec defines an XML schema; the SCP spec defines a
special FAST-encoded method. For the most common uses of FAST, the
benefits of the special encoding do not outweigh the complexity it
introduces.The SCP spec could easily define a template definition message where
the template contents are transmitted as XML embedded in a unicode
string field.The cost of exchanging templates via XML is size: no doubt the special
encoding will take up less space. In the typical case, template exchange
is going to be a one-time cost incurred when the connection is
established. Using the special encoding to save bytes then is a
misplaced optimization.On the other hand, exchanging templates via XML can simplify both the
specification and the implementations built around it. Since the FAST
spec defines the schema, most implementations will already be parsing
it, so why not reuse that code?Additionally, the special encoding is less expressive than the XML
encoding. For example, there is no room in the special encoding for the
“foreign elements” that are used to represent a template’s reset
property, which is why it gets a distinct field in the special encoding.
A later version of SCP will have difficulty introducing changes to the
format in a simple way.I am aware of some scenarios where one might want to transmit templates
more frequently, in which case the special encoding would make more
sense, but at this point it seems premature to cater to least common
settings. It would not be unreasonable to define an alternate encoding
in a later version of SCP, when we have a need for a compressed template
representation. Until then, the special encoding is complicating the SCP
specification, which in turn complicates implementations, which keeps it
out of the market.
[ original email was from Scott McCaskill - smccaskill@zonetrading.com ]
> BTW, support for foreign components are in the upcoming draft (and are
present in the SCP Example kit that has been distributed in the
working group)/David
Is there a way I can get access to the Example kit? I’m assuming it’s different than the document on this site which describes SCP 1.0.
–Scott