Proposal to change "subscribe" msg used to setup routing paths at the msg node

[pchainho]

From the discussion I had yesterday with @sdruesedow I've realised the subscribe message to setup the sync routing path for the observer is not well designed.

It requires the msg node to have knowledge about the data sync algorithm and creating this dependency at the msg node is not good. Also it does not provide a generic procedure to setup routes at the msg node. In order to overcome these limitations I propose a simpler and cleaner subscribe message:

https://slack-files.com/T0BFPHRRN-F0PLVAF6F-38618f3a75

With this message the setup of the routing path would be very simple:

1- who is subscribing: body.source or from in case there is no body.source 2- what to subscribe: body.subscribe ie a list of URLs to be subscribed to

@sdruesedow @FredLuart @NicoApizee let me know what do you think

[sdruesedow]

This approach looks much simpler to me, because the MN does not need internal knowledge about things like: "I need to add /changes to the url." or "childrenResources must be added like /children/child" etc. I support it. The required changes in the MN are rather small.

[FredLuart]

This sounds good, static URL routing is better for us

[pchainho]

To be consistent, the same approach should be applied on the reporter side when the object is created.

Right now, the routing path is set when the object address is allocated, but it requires the Msg Node Address Allocation functionality to know the data sync mechanisms ie to add listeners to /subscription. To avoid this, it is proposed to have a dedicated Subscribe message similar to the one used on the observer side.

[pchainho]

I've updated the specs according to this proposal:

https://github.com/reTHINK-project/dev-service-framework/blob/develop/docs/specs/messages/data-sync-messages.md

Also the allocation request message was changed since now this won't trigger anymore the routing setup at the msg node for new created messages:

https://github.com/reTHINK-project/dev-service-framework/blob/develop/docs/specs/messages/address-allocation-messages.md#address-allocation-request

Finally, a new Subscribe message sent by the Observer runtime to the reporter msg node was added, to fix the issue we found today in our interoperability session:

https://github.com/reTHINK-project/dev-service-framework/blob/develop/docs/specs/messages/data-sync-messages.md#reporter-data-sync-routing-path-setup-request-at-reporter-message-node-for-a-new-data-object

with the corresponding unsubscribe message:

https://github.com/reTHINK-project/dev-service-framework/blob/develop/docs/specs/messages/data-sync-messages.md#request-to-remove-data-sync-routing-path-at-reporter-message-node

Data flows were also updated:

https://github.com/reTHINK-project/dev-service-framework/blob/develop/docs/specs/dynamic-view/data-sync/data-object-creation.md

https://github.com/reTHINK-project/dev-service-framework/blob/develop/docs/specs/dynamic-view/data-sync/data-object-subscription.md

https://github.com/reTHINK-project/dev-service-framework/blob/develop/docs/specs/dynamic-view/data-sync/data-object-unsubscription.md

As agreed today, we should make these changes for the current release, which should be done in separated branches to avoid impact on other components and functionalities.

[jhamfler]

@pchainho Shouldn't this be { "childrenResources" : ["<scheme>://<sp-domain>/<identifier>", ...] } instead of { "childrenResources" : {"["<scheme>://<sp-domain>/<identifier>", ...]} }?

[pchainho]

thx for this @jhamfler I guess this is a json syntax typo. I've fixed that.

[pchainho]

This has been already implemented by Msg Nodes and Sync Manager in the Core Runtime