Imported from previous forum
FAST was released with an encoder / decoder (FAST 1.1) and a simple Session Control Protocol 1.0.
The current proposal for SCP 1.1 includes exchange of templates.
As the primary purpose for FAST is the distribution of market data - a primary usage model will be market places distributing data to multiple recipients. In these scenarios the need for and the requirement to support in-band template exchange does not exist and may even be seen as a detriment.
With this in mind - I think we should consider making template exchange an optional layer or component that sits on top of the existing FAST 1.1 and SCP 1.0.
This way those market places that do not need the use of template do not need to implement it to be FAST compliant.
If this idea has merit we need to respond in a timely manner as the goal is to publish a SCP 1.1 draft soon.
I believe we can choose between:
- Putting template exchange in a separate spec
This would make the rest of the SCP spec really small.
We could move it to the core spec, but the three SCP
messages defined in SCP 1.0 are different by nature and
fit better in a layer on top of the core FAST protocol.
- Keep it in the SCP spec, but designate it as optional.
I think template exchange belongs in the SCP spec.
As you point out, there are a number of use cases where
template exchange is less or not relevant.
My view is that you can comply with the FAST spec without
using any of the messages in the SCP spec.
That said, I strongly encourage the use of Hello, Alert,
and Reset when appropriate and not try and invent some
other mechanism with similar semantics. We should also
endeavour to add mechanisms to the SCP that would support
generic requirements as they arise / get known.
/Rolf
FAST was released with an encoder / decoder (FAST 1.1)
and a simple Session Control Protocol 1.0.The current proposal for SCP 1.1 includes exchange of templates.
As the primary purpose for FAST is the distribution of market
data - a primary usage model will be market places distributing
data to multiple recipients. In these scenarios the need for
and the requirement to support in-band template exchange does
not exist and may even be seen as a detriment.With this in mind - I think we should consider making template
exchange an optional layer or component that sits on top of the
existing FAST 1.1 and SCP 1.0.This way those market places that do not need the use of template
do not need to implement it to be FAST compliant.If this idea has merit we need to respond in a timely manner as
the goal is to publish a SCP 1.1 draft soon.