Subscribing and Registering Subscribed items is confusing

[jwise-mfg]

We need to clarify the handshake for subscribing to elements.
Currently you make a call to create a subscription, then another call to register monitored items. Its not clear if you can make that register call repeatedly (additive). There's no way to remove monitored items short of deleting the subscription. The group discussed two options:

• Option 1: Make Subscribe-and-register a single call. If you want to change monitored items, delete the subscription and start again.
• Option 2: Keep the two-step, document that register is additive, add a method to unregister.

@jwise-mfg to discuss with OPCF to maintain alignment, document, and close.

[matthewGEA]

Current prototype:

POST /subscriptions
Create subscription specifying QoS0 or QoS2. Maps to OPC UA POST /createsubscription

POST /subscriptions/{subscriptionId}/objects
Registers monitored items, and for QoS0, starts the stream. Maps to OPC UA POST /createmonitoreditems

NOTE: there is currently no mapping to OPC UA POST /deletemonitoreditems

POST /subscriptions/{subscriptionId}/sync
Get buffered data. Maps to OPC UA POST /publish

DELETE /subscriptions/{subscriptionId}
Delete the whole subscription. Maps to OPC UA POST /deletesubscriptions

@jwise-mfg

OPTION 2 Proposal

Similar to #115
Remove endpoint POST /subscriptions/{subscriptionId}/objects

Replace with the following new methods:

POST /subscriptions/{subscriptionId}/createItem
Add new monitored items to subscription. Continues to map to OPC UA POST /createmonitoreditems

POST /subscriptions/{subscriptionId}/deleteItem
Delete monitored items from subscription. Maps to OPC UA POST /deletemonitoreditems where there is no mapping today

NOTE: have both add and delete above work for any subscription, whether it is QoS0 or QoS2.

GET /subscriptions/{subscriptionID}/stream
endpoint to receiving stream. This new endpoint would allow a client to reconnect after a network disconnection, where using the same subscriptionID reconnects to the stream that was lost. This stream endpoint also allows clients to remain connected to a single stream and begin receiving updates whenever new monitored items are added to the subscription. OPC UA REST does not include a way to stream subscription data, so this method will continue to be novel.

[jwise-mfg]

we need to add /deletemonitoreditems per OPCF. RFC updated, moving this issue to spec.

[RickBullotta]

One thing that is missing is a concept akin to MQTT's "persistent sessions". We also need to describe scenarios when the server/provider will automatically delete subscriptions when a client connection is lost. We may need a heartbeat mechanism also.

The overall subscription concept seems a bit too "unbaked" right now.

[jwise-mfg]

Sounds like you're signing up to write this section of the spec!

[matthewGEA]

@RickBullotta please review what I proposed here #125 (comment) and see if that covers what you have in mind regarding an analog to MQTT persistent sessions.