View Issue Details

IDProjectCategoryView StatusLast Update
0008153Part 81: UAFX Connecting Devices and Information ModelSpecpublic2022-08-19 13:53
ReporterMatthias Damm Assigned ToGeorg Biehler  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.00.00 RC3 
Target Version1.00.00Fixed in Version1.00.00 Release 
Summary0008153: Issues with PubSubCommunicationFlowConfigurationType and SubscriberConfigurationType Missing configuration parameters
Description

I have different issues with the PubSubCommunicationFlowConfigurationType and SubscriberConfigurationType.

(1) Optional on PubSubCommunicationFlowConfigurationType and SubscriberConfigurationType
Based on discussions with Paul and Georg in prototyping meetings I understand why everything is optional for the Publisher side but I do not see why the subscriber address is mandatory. SubscriberConfigurationType.Address should be optional. I assume in most cases the address can be configured on the Publisher and the address of the Subscriber is either the same or can be derived from the Publisher Address. If this must be configured by a user, it would be very annoying if a lot of subscriber addresses must be configured for a multi-cast scenario where all subscriber addresses would be identical to the publisher address.

(2) Missing configuration parameters
The following parameters are necessary if you want to support more than one protocol option in FX:

  • TranportProfileUri
  • HeaderLayoutUri

The message encoding is not part of the address schema. This would be a problem for the broker transports. This information is only indicated by the TranportProfileUri.

Even if the Periodic Fixed Header Layout is the default for FX, it is necessary to provide the dynamic option for some use cases e.g. autonomous Publisher.
Periodic Fixed can be defined as default if optional HeaderLayoutUri is not provided.

TagsNo tags attached.

Activities

Georg Biehler

2022-07-27 18:19

developer   ~0017187

to (1)
Idea would then be to set as optional and specify rules, if not supplied. Sounds like a good idea, since it would reduce the user interface for setting the parameters. Lets specify the rules first and then see, whether it will simplify the user interface. If yes, I would be in favor implementing it.

to (2)
Lets add the two parameters to the flow attribute as optional and specify rules, when omitted.

Georg Biehler

2022-08-02 07:50

developer   ~0017198

Fixed both issues

Paul Hunkar

2022-08-19 13:53

manager   ~0017342

Reviewed text updates in call, agreed to changes, closed issue

Issue History

Date Modified Username Field Change
2022-07-27 06:02 Matthias Damm New Issue
2022-07-27 12:38 Paul Hunkar Summary Issues with PubSubCommunicationFlowConfigurationType and SubscriberConfigurationType => Issues with PubSubCommunicationFlowConfigurationType and SubscriberConfigurationType Missing configuration parameters
2022-07-27 18:19 Georg Biehler Note Added: 0017187
2022-07-28 18:36 Georg Biehler Assigned To => Georg Biehler
2022-07-28 18:36 Georg Biehler Status new => assigned
2022-08-02 07:50 Georg Biehler Status assigned => resolved
2022-08-02 07:50 Georg Biehler Resolution open => fixed
2022-08-02 07:50 Georg Biehler Fixed in Version => 1.00.00 Release
2022-08-02 07:50 Georg Biehler Note Added: 0017198
2022-08-19 13:53 Paul Hunkar Status resolved => closed
2022-08-19 13:53 Paul Hunkar Note Added: 0017342