Imported from previous forum
Hi all,
Here is a small extension proposal aimed at making things easier for FAST decoder writers: a MaxLength string attribute
FAST compilers need to know the maximum string size for a field in order to be able to use pre-allocated string buffers in memory.
Generally this maximum string size is given in the user documentation going with the FAST templates but it should also be in the templates so that compilers can get that information and use it.
On the same topic, Min/Max attributes for integers would be a good thing too. Or maybe smaller types like Integer8 and Integer16 would be enough.
I know some people would rather like to remove and not add new features but I think it’s better to improve what we already have.
BTW is there a page somewhere with the all the officials 1.2 extension proposals?
Marc
Marc,
you will find the proposal online at:
http://www.fixprotocol.org/documents/4267/FAST%201.2%20Extension%20Proposal%20v5.pdf
Best,
Rolf
Hi all,
Here is a small extension proposal aimed at making things easier for
FAST decoder writers: a MaxLength string attributeFAST compilers need to know the maximum string size for a field in order
to be able to use pre-allocated string buffers in memory.Generally this maximum string size is given in the user documentation
going with the FAST templates but it should also be in the templates so
that compilers can get that information and use it.On the same topic, Min/Max attributes for integers would be a good thing
too. Or maybe smaller types like Integer8 and Integer16 would be enough.I know some people would rather like to remove and not add new features
but I think it’s better to improve what we already have.BTW is there a page somewhere with the all the officials 1.2 extension
proposals?Marc
Thanks Rolf,
Is there an official process to comment and/or submit proposals or is this forum the right place to do so?
Are there also some deadlines for this process?
Tanks,
Marc
Marc,
you will find the proposal online at:
http://www.fixprotocol.org/documents/4267/FAST%201.2%20Extension%20Prop-
osal%20v5.pdfBest, Rolf
Hi all,
Here is a small extension proposal aimed at making things easier for
FAST decoder writers: a MaxLength string attributeFAST compilers need to know the maximum string size for a field in
order to be able to use pre-allocated string buffers in memory.Generally this maximum string size is given in the user documentation
going with the FAST templates but it should also be in the templates
so that compilers can get that information and use it.On the same topic, Min/Max attributes for integers would be a good
thing too. Or maybe smaller types like Integer8 and Integer16 would
be enough.I know some people would rather like to remove and not add new
features but I think it’s better to improve what we already have.BTW is there a page somewhere with the all the officials 1.2 extension
proposals?Marc
Marc,
we’ve discussed different parts of the proposal during our bi-weekly mdowg conf calls. We’ve also asked people to feedback during the calls as well as in the forum.
I’m hoping that we can get to a rough consensus during next week’s conf call. Please join that call if you have time.
In the mean-time, please comment on the proposal here in the forum. It would be very relevant to get your feedback as you and your team work with hardware acceleration.
Once we have a rough consensus on the scope of a proposed 1.2, we’ll put together a complete proposal for consideration by the gtcgov board first and then the GTC.
I’m hoping that we can complete this process during Q1 of 2009.
Best,
Rolf
Thanks Rolf,
Is there an official process to comment and/or submit proposals
or is this forum the right place to do so?Are there also some deadlines for this process?
Tanks,
Marc
Marc -
I think additional constraints on the fields and types in the template may be a good thing. However, I think they’re best expressed using the extensibility feature of the template syntax. This way a constraints specification can be developed separately from the core specification.
An optimizing processor could then utilize the extra information if present. A simpler implementation would just ignore it automatically as specified in the core specification.
An hypothetical example:
/D
Hi all,
Here is a small extension proposal aimed at making things easier for
FAST decoder writers: a MaxLength string attributeFAST compilers need to know the maximum string size for a field in order
to be able to use pre-allocated string buffers in memory.Generally this maximum string size is given in the user documentation
going with the FAST templates but it should also be in the templates so
that compilers can get that information and use it.On the same topic, Min/Max attributes for integers would be a good thing
too. Or maybe smaller types like Integer8 and Integer16 would be enough.I know some people would rather like to remove and not add new features
but I think it’s better to improve what we already have.BTW is there a page somewhere with the all the officials 1.2 extension
proposals?Marc
David,
I think additional constraints on the fields and types in the template
may be a good thing. However, I think they’re best expressed using the
extensibility feature of the template syntax. This way a constraints
specification can be developed separately from the core specification.An optimizing processor could then utilize the extra information if
present. A simpler implementation would just ignore it automatically > as specified in the core specification.
Yes but by doing this, the information will not be normalized. So it
could be MaxLength or MaxSize or StringLength or whatever.
If some attributes are added to the FASt spec then people will be
reminded of specifying them and everybody will use the same
unambiguous names.
Marc
An hypothetical example:
/D
Hi all,
Here is a small extension proposal aimed at making things easier for
FAST decoder writers: a MaxLength string attributeFAST compilers need to know the maximum string size for a field in
order to be able to use pre-allocated string buffers in memory.Generally this maximum string size is given in the user documentation
going with the FAST templates but it should also be in the templates
so that compilers can get that information and use it.On the same topic, Min/Max attributes for integers would be a good
thing too. Or maybe smaller types like Integer8 and Integer16 would
be enough.I know some people would rather like to remove and not add new
features but I think it’s better to improve what we already have.BTW is there a page somewhere with the all the officials 1.2 extension
proposals?Marc
Marc -
Of course it can be formalized. Just because it isn’t part of the core specification doesn’t mean you cannot write a formal specification for it. Constraints and optimization hints of this sort are perfectly suitable for layering using the extensibility mechanism.
If this is important and general enough, I think FPL could be the owner of such a specification. Until then, if you’ve got some ideas about constrains and optimization hints, I suggest you try to formalize them in a proposal and share it with FPL and the forum.
Kind regards,
/David
Yes but by doing this, the information will not be normalized. So it
could be MaxLength or MaxSize or StringLength or whatever. If some
attributes are added to the FASt spec then people will be reminded of
specifying them and everybody will use the same unambiguous names.Marc
[ original email was from Zoltan Vekony - zoltan.vekony@web.de ]
Hi all,
what are you thinking about a maximum length not only for the strings, but also for byte array and for repeating groups (sequences) which may be equal to a maximum for the sequence’s length field:
// direct max attribute to the sequence, implicit length field
Bye
Zoltan
Hi all,
Here is a small extension proposal aimed at making things easier for
FAST decoder writers: a MaxLength string attributeFAST compilers need to know the maximum string size for a field in order
to be able to use pre-allocated string buffers in memory.Generally this maximum string size is given in the user documentation
going with the FAST templates but it should also be in the templates so
that compilers can get that information and use it.On the same topic, Min/Max attributes for integers would be a good thing
too. Or maybe smaller types like Integer8 and Integer16 would be enough.I know some people would rather like to remove and not add new features
but I think it’s better to improve what we already have.BTW is there a page somewhere with the all the officials 1.2 extension
proposals?Marc
Zoltan,
Good point. The more information for optimizing the better!
Best regards,
Marc
Hi all,
what are you thinking about a maximum length not only for the strings,
but also for byte array and for repeating groups (sequences) which may
be equal to a maximum for the sequence’s length field:
// direct max attribute to the
sequence, implicit length field
//
max attribute for the explicit length fieldBye Zoltan
Hi all,
Here is a small extension proposal aimed at making things easier for
FAST decoder writers: a MaxLength string attributeFAST compilers need to know the maximum string size for a field in
order to be able to use pre-allocated string buffers in memory.Generally this maximum string size is given in the user documentation
going with the FAST templates but it should also be in the templates
so that compilers can get that information and use it.On the same topic, Min/Max attributes for integers would be a good
thing too. Or maybe smaller types like Integer8 and Integer16 would
be enough.I know some people would rather like to remove and not add new
features but I think it’s better to improve what we already have.BTW is there a page somewhere with the all the officials 1.2 extension
proposals?Marc