Interface: Questions about property inheritance of the MessageContext object

[benthor]

Section 9.1.3 of the API Draft states:

A MessageContext object contains metadata for the Messages to be sent or received.

messageData := "hello"
messageContext := NewMessageContext()
messageContext.add(parameter, value)
Connection.Send(messageData, messageContext)

At this point, the reader gains the impression that messageContext is created independently of any Connection/Selection Properties.

However, Section 9.1.3.7 goes on to state:

Name: msgReliable
Type: Boolean
Default: the queried Boolean value of the Selection Property reliability (Section 6.2.1)

This raises numerous questions:

• Does this mean that Selection Properties have to be "in scope" whenever a MessageContext object is created?
  • (i.e., shouldn't NewMessageContext() take the current Selection Properties as an argument?)
• How does, a Selection Property of, e.g., Reliability: Prefer even meaningfully map to a Boolean?
  • (i.e., why is the Property Type a Boolean instead of a Preference?)

(Note that the msgOrdered property from Section 9.1.3.3 raises similar questions)

[mwelzl]

That's a great catch, thanks! I agree that it should be possible to create a messageContext independent of Connection/Selection properties.

A static default may be bad: one may e.g. always have msgOrdered=true, not care about it, and never be able to benefit from a Connection that can do msgOrdered=false.

So, instead, I'm tempted to suggest that the default will be assigned (unless the value has been specifically assigned with "add" as in your example above) based on Connection/Selection properties upon use - during the Send call. But this also easily gets bad: it would be an easy mistake to miss this in a TAPS Transport System implementation, and ... if I want to read the value of this parameter of the messageContext, what do I get? Maybe we could define a new special value: "to be updated upon use" ?

Tricky. Ideas, anyone?

[benthor]

In my implementation, I've tentatively changed the Boolean Type to the Preference enum Type

This has a number of advantages:

• The default Preference value of Ignore, which the spec defines as "no preference" unambiguously stands for "simply inherit this Property from the connection properties when sending this message"
• Require and Prohibit are equivalent to the Boolean semantics from the spec
• The possible Preference values of Avoid and Prefer are essentially equivalent to Prohibit and Require, but are understood to not generate errors, even if the underlying connection has no support for the desired Property

Note that this setup alone does not allow the MessageContext Object to "query" a default value for this Property from other contexts. It is not quite clear to me why this would ever be needed in practice.

[mwelzl]

Interesting! I don't think we should spec it using the Preference type though (seems like a bit of a hack: a "Preference" isn't what this is, and the re-interpretation of Avoid and Prefer isn't too nice either... but that's ok for an implementation!).

We could have the type definition as follows:
Type: Boolean or Ignore
(this is similar in style to the type definitions in e.g. 8.1.4, 8.1.8, 8.1.9)
Default: Ignore

... and we could explain that Ignore here means to inherit the value from the connection properties when sending this message. As for querying a default value, I agree that this isn't something one would need in practice but I wanted to be consistent here (everything can be queried as far as I understand) - anyway, querying without changing anything should yield the value Ignore, so that's ok, then.

If folks agree with this, I can make a PR.

[philsbln]

I guess making this inheritance mechanism more obvious could really help here. But using "ignore" for "inherit" or "default" is a bad choice, though.

When designing this, we rather thought the message context to be something like a dictionary, where we put all "changes" we want to apply to the message, but making it somewhat of a strongly typed object may require constructing it from the connection in order to derive the defaults.

[tfpauly]

Agreed with @philsbln. We should make the inheritance of properties from connection-wide preferences onto messages more clear.

[tfpauly]

Suggestion:

In 9.1.3, explain that if you don't set a specific property on a message, the connection/selections properties apply based on what the connection has, and the ones that don't inherit from a connection just use their default.

[mwelzl]

[Note to self] ... and additionally put specific text about this in the description of the properties where the default is described as "inheriting" from the Connection.