Pmap field placement

, ,
1

Imported from previous forum

2

All,

following up on today’s call;

a few people on the call today voiced concerns about the added complexity of FAST as a consequence of the pmap field placement proposal.

If I understood the comments correctly, the mix of metadata and data would be problematic in some of the current implementations.

I’d like to get your comments on this as well as suggestions on how we should go forward.

Thx,
Rolf

3

[ original email was from Greg Orsini - greg.orsini@orcsoftware.com ]
> If I understood the comments correctly, the mix of metadata and data

would be problematic in some of the current implementations.

Separation of metadata and data is desirable for a clean design, but it is sometimes necessary to compromise for the sake of optimization.

For us C++ types, we deal with separate class declaration and implement in *.h and .cc files. For the sake of optimization, this line has been broken with inline implementation in the declaration - that is, inline functions.

I believe a similar argument could be made for a pragmatic mixing of metadata and data for FAST.

Regards, Greg.

4

My view on this one is that we should give the clear design priority at this stage and keep the pmap restricted to metadata. It appears to me to be more of an extension for a FAST 2.0, whatever that may be. There are still implementations out there struggling with FAST 1.1 compliance. I think it is better to let the implementations become more mature and the number of FAST experts grow before optimizing data into the pmap. The bitgroup extension is more significant and already helps a lot with the fields having a very small range of values.

Regards,
Hanno.

All,

following up on today’s call;

a few people on the call today voiced concerns about the added
complexity of FAST as a consequence of the pmap field placement
proposal.

If I understood the comments correctly, the mix of metadata and data
would be problematic in some of the current implementations.

I’d like to get your comments on this as well as suggestions on how we
should go forward.

Thx, Rolf

5

I strongly agree with you on this Hanno

  1. The presence map then is no longer a presence map - a fundamental recoding of most existing applications will have to occur.
  2. Usage of this feature is clearly is not backwardly compatible to previous implementations of FAST.
  3. There are no proven temporal or spatial quantitative benefits demonstrated.
  4. Breaking the abstraction of Presence Map and making it Presence Map with data sometimes being present is a major conceptual change and will lead to increased test cases to validate an implementation.

I think we should also take a more conservative stance in terms of protecting the existing install base. We should say prove why this feature should be in place - FIX is probably one of the most accomodating standards organizations in existence - we often say “you want something in the protocol we will add it” - and this is an important part of our success - but it is also part of our undoing - with something as non-trivial (I did not say complex) as FAST and with the number of installations now in existence - I think we have to put up a larger firewall and require those proposing “good” features to prove both their business and technical cases before standardizing.

I would also like to paraphrase something Rolf said on yesterday’s call in American Colloquial as “when in doubt leave it out”. We can always standardize a contentious feature in the future. Removing a feature once standardized is a near impossibility. If we can’t come to consensus - the feature should not be codified as part of the standard.

My view on this one is that we should give the clear design priority at
this stage and keep the pmap restricted to metadata. It appears to me to
be more of an extension for a FAST 2.0, whatever that may be. There are
still implementations out there struggling with FAST 1.1 compliance. I
think it is better to let the implementations become more mature and the
number of FAST experts grow before optimizing data into the pmap. The
bitgroup extension is more significant and already helps a lot with the
fields having a very small range of values.

Regards, Hanno.

All,

following up on today’s call;

a few people on the call today voiced concerns about the added
complexity of FAST as a consequence of the pmap field placement
proposal.

If I understood the comments correctly, the mix of metadata and data
would be problematic in some of the current implementations.

I’d like to get your comments on this as well as suggestions on how we
should go forward.

Thx, Rolf