EmberPlusViewer sends illformed GetDirectory requests

[BossFeratu]

I observed that if I try to expand a function or matrix in the EmberPlusViewer, it sends a GetDirectory with the type of its parent being "Node", not "Function" or "Matrix". Since my provider doesn't really care for that but uses the received structure for the reply, it also replies with the parent being "Node". This leads to the EmberPlusViewer inserting a new node at the same level as the original function, with the same number.
I tried to find hints in the Ember+-specification if this is legal behaviour, but couldn't find anything.
We have 3 behaviours to discuss:

• Is it legal to send a "GetDirectory" with the wrong parent type? (I think it's ok to interpret "Node" as a "base class" of "Function" and "Matrix")
• Is it legal to reply with the same wrong type? (That must have been my assumption when I programmed the provider)
• Is it a bug that the EmberPlusViewer then inserts a new node? (I think, it is)

I am pretty sure that former versions of EmberPlusViewer behaved different, now this avoids to get labels for a matrix if they reside in the matrix' subtree.
My EmberPlusView version is 2.40.0.7.

Cheers,

Stefan

[KimonHoffmann]

Hi Stefan!

Thanks for reporting this!
Regarding the three behaviors you mentioned I take a stab at (partially) answering them:

1. The question arises from the fact that queries use numbers and, since numbers are unique in a given scope, the correct type is implied and the redundant type information contained in the message creates the confusion.
   In my opinion a request specifying a mismatching type for a node is illformed, because the "inheritance relationship" you assume is not supported by the ASN.1 definition.
   For reasons of robustness and integrity a provider should reject such illformed messages, because in a broader scope, such a message could be an indication of a client using an outdated node cache to form its requests. Replying with what the client expects just moves potential problems arising from this inconsistency up the hierarchy.
2. Since a number must be unique within a given scope, sending out messages with the same number but different types is illegal, regardless of whether this is a reply to an already faulty client, or a provider initiated message, because it would imply the existence of two entities within this scope, which share the same number. Regarding the special case of replies to illformed requests the additional argument of robustness was already made as part of point 1.
3. It surely is, but this is only the visible result of the more severe issue that the viewer creates faulty requests.