isCompatible() considered harmful

[mdavidsaver]

Fixing isCompatible() is proving quite tedious because of code like the following. note the field[3], which is asserting not just the existence of string 'display.field', but that it is the 4th of 5 fields.

This makes even the slightest change to the display substructure a compatibly break, and would tie my hands wrt. replacing 'display.format'!

Given this, and the grief caused by returning false with no indication of which test has failed, I'm inclined to stub the is*() methods to always return true. Code calling methods documented to return NULL really should be checking for this case (though I know this is often not done).

normativeTypesCPP/src/ntfield.cpp

Lines 130 to 134 in 2d186d4

	f = fields[3];
	if(names[3].compare("format")!=0) return false;
	if(f->getType()!=scalar) return false;
	s = static_pointer_cast<const Scalar>(f);
	if(s->getScalarType()!=pvString) return false;

[mdavidsaver]

@MarkRivers @brunoseivam I think this would impact AD.

[brunoseivam]

Hi Michael,

I think (in AD's case at least) that the field order does not matter. The code is just testing that the received PVStructure is, in fact, conformant to the NTNDArray definition. All fields are accessed by name thereafter. I believe field order should be considered an implementation detail and should not be relied upon regardless.

At the same time, I understand that this would mean having to rewrite all isCompatible tests in a different way.

[brunoseivam]

Also, as I think more about it, the change you are proposing to the structure would be a breaking change anyway, right? Will the "version" of the normative types be bumped? Maybe isCompatible should take a version parameter (isCompatible("1.0"))?

[mdavidsaver]

the change you are proposing to the structure

Better make that "proposed" in the past tense. epics-base/pvDataCPP#62 was created back in January, and merged last night. Which then triggered various CI failures.

Maybe isCompatible should take a version parameter

How would this be used? (and who would do the work of implementing?)

Anyway, I don't see how it helps avoid a compatibility break. With epics-base/pvDataCPP#62 merged, even if isCompatible() were fixed, older AD clients would refuse to use NTNDArrays from newer servers. All because of a field which isn't actually used...

[brunoseivam]

The way I see it, isCompatible is a validator against the NT spec. As a client, I want to be able to ask "is this structure here that I got from the network usable as a standard-defined NTNDArray?".

Changing the display structure breaks all NT structures that include it (even if no one uses display at the moment). Hence, an NT structure version bump is warranted. I don't know how to properly handle different NT structure versions, though (as a client or as a server). Was this discussed by the core developers in the past when normative types was proposed/developed?