Feature Description
All message handlers are paired with a QualifiedName.
Upon subscription of a MessageHandler, it's QualifiedName is required by the respective message type it's registry.
Furthermore, each Message has a so-called MessageType: a combination of the QualifiedName and a version field.
Not that right now, pairing of Message to handler is done solely on the QualifiedName in the MessageType.
However, it would be beneficial if a MessageHandler can dictate a specific version and/or version range for the given QualifiedName it is subscribed for.
Example use case
In doing so, we could for example adapt the MessageHandler to be an in-place upcaster. This idea would hold as the message's payload can be an intermediate format like JSON. Then, if the version range is specified through some to decide upon mechanism, it becomes the message handler's job to upcast the given message.
This solution would not only deprecate the current upcaster support to some extent, it would more importantly allow component-specific upcasting.
Current Behaviour
A MessageHandler and Message are matched based on the QualifiedName used during subscription of the handler and the QualifiedName contained in the MessageType of the Message.
Wanted Behaviour
A MessageHandler can specify a form of VersionRange or VersionSpecifier during subscription, making the handler eligible for a sub-set of message versions.
Possible Workarounds
None.
Feature Description
All message handlers are paired with a
QualifiedName.Upon subscription of a
MessageHandler, it'sQualifiedNameis required by the respective message type it's registry.Furthermore, each
Messagehas a so-calledMessageType: a combination of theQualifiedNameand a version field.Not that right now, pairing of
Messageto handler is done solely on theQualifiedNamein theMessageType.However, it would be beneficial if a
MessageHandlercan dictate a specific version and/or version range for the givenQualifiedNameit is subscribed for.Example use case
In doing so, we could for example adapt the
MessageHandlerto be an in-place upcaster. This idea would hold as the message's payload can be an intermediate format like JSON. Then, if the version range is specified through some to decide upon mechanism, it becomes the message handler's job to upcast the given message.This solution would not only deprecate the current upcaster support to some extent, it would more importantly allow component-specific upcasting.
Current Behaviour
A
MessageHandlerandMessageare matched based on theQualifiedNameused during subscription of the handler and theQualifiedNamecontained in theMessageTypeof theMessage.Wanted Behaviour
A
MessageHandlercan specify a form ofVersionRangeorVersionSpecifierduring subscription, making the handler eligible for a sub-set of message versions.Possible Workarounds
None.