-
Key: C2MS-10
-
Status: closed
-
Source: NASA ( Mr. John Bugenhagen)
-
Summary:
(Mnemonic Value Request) Section 7.8.1
- In GMSEC, re-requesting on the same name is (per an e-mail thread with GSFC) defined as replacing the previous subscription instead of being additive/subtractive. Is that notion being kept in this spec? If so, this should be explicitly defined in the specification.
- DURATION: When there is no DURATION specified, but a component decides to have a maximum duration anyway, data will arbitrarily stop. This is problematic for subscriptions by a non-UI system component, like a script that checks telemetry values or a roll-up / derived capability that subscribes to data to produce second-level data. Mechanisms to avoid such stoppages in data, such as periodically resubscribing are wasteful and potentially inconsistent between components.
-
Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:23 GMT
-
Disposition: Resolved — C2MS 1.0
-
Disposition Summary:
Part covered by issue 8, DURATION issue to be fixed by adding final message
Rerequesting will be solved by resolution to issue 8, request-id. Duration will be solved by adding paragraph near duration description that final-message flag should always be set on sending final message. At the very end of section 8.8.1.3, where self-imposed duration is discussed, add this: "If a data provider does self-impose a maximum duration, the FINAL-MESSAGE field should be set appropriately in the last message sent."
-
Updated: Tue, 8 Oct 2019 17:51 GMT
C2MS — Mnemonic Value Request comments
- Key: C2MS-10
- OMG Task Force: Command and Control Message Specification (C2MS) 1.0 FTF