Source: Airbus Group ( Oliver Kellogg)
In order to use an IDL type as a topic type, some additional methods are required to be generated (such as methods for creating DataReaders and DataWriters).
Implementations have invented their own mechanisms in this area:
- One product might support the notion that by default all structured types can be used as topic types, defining a mechanism to selectively switch off that assumption
- Another product might require a pragma to be used for switching on the additional code generation for topic types
A built in annotation should be added for distinguishing topic types from non topic types.
Reported: DDS-XTypes 1.2b1 — Mon, 12 Feb 2018 06:46 GMT
Disposition: Resolved — DDS-XTypes 1.3
Introduce a @DDSTopic annotation that allows marking DDS Topic Types
Define a new annotation that can be used to indicate that certain types are intended to be used as DDS Topic Types.
There are some related precedents:
This @DDSTopic annotation parallels the @DDSService annotation defined in DDS-RPC. The definition is of @DDSService
Note that DDS-RPC also defines the following annotations:
This specification which was released after DDS-RPC introduced a new notation for marking services:
In IDL42 there are three pre-defined values of for the platform:
- "CORBA" indicates that the service should be made accessible via CORBA.
- "DDS" indicates that the service should be made accessible via DDS.
- "*" (an asterisk) indicates any platform. This is the default value.
So a definition that follows what was done in DDS-RPC could be:
Whereas a definition that follows what was done in IDL 4.2 could be:
Or some other name instead of "topic", perhaps "message" if we consider it sufficiently generic:
Note that all MQTT (http://mosquitto.org/man/mqtt-7.html), Amazon Pub-Sub (https://aws.amazon.com/pub-sub-messaging/), and Google PubSub (https://cloud.google.com/pubsub/docs/overview) use the concept of messages sent to a Topic.
If we used a @topic definition in IDL and we wanted to be able to specify the Topic name would need to combine it with another annotation (in DDS-XTYPES, not IDL) to do this. For example @DDSTopicName. So finally we would have:
IDL4 -> @service , @topic. These allow specifying the platform, e.g. @service("DDS") or @topic("DDS"). If not parameter is specified the default is @service("*"), @topic("*").
Then in DDS-RPC we have @DDSServiceName("MyService"), @DDSRequestTopic("MyServiceRequest"), @DDSReplyTopic("MyServiceReply")
Ans in DDS-XTYPES we have @DDSTopicName("MyTopic").
Alternatively we could try to eventually push all this into the IDL annotations. For example:
So for now we could add @topic to the DDS-XTYPES and push it to IDL4 later.
How would annotations with parameters appear in XML? Is it legal to do something like:
Updated: Tue, 8 Oct 2019 17:55 GMT