Proposal for a MaxLength string attribute

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 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

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.pdf

Best, Rolf

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,

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 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

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 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 -

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

// max attribute for the explicit length field

Bye
Zoltan

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

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 field

Bye Zoltan

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