You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our application employs an internet-based synchronization mechanism to share project data across multiple devices, with each device having its own designated provisioner within the network.
Upon implementing this, we encountered an unforeseen behavior of the library as detailed below.
Unexpected behaviour
When a local provisioner is removed from the network, the data of the next available provisioner gets overridden as can be seen in MeshNetwork+Provisioner.swift.
In our scenario, this causes an issue when a user removes the device at hand from the network,
while other provisioners/devices remain provisioned and are properly configured.
So no "self-healing" would be required.
However, if such changes were synchronized, it would result in overriding the provisioner data of another smartphone.
Proposed solution
We kindly suggest the removal of the self-healing mechanism within the library. Instead, we propose that developers using the library should provide alerts to end users, guiding them to avoid potential misconfigurations or erroneous actions. This way, the responsibility of ensuring proper network configurations would be shifted away from the library and no guessing about developer's intentions would be needed.
The text was updated successfully, but these errors were encountered:
Hello,
I understand the issue with overriding the next available provisioner. However, may I ask you to elaborate on:
In our scenario, this causes an issue when a user removes the device at hand from the network,
while other provisioners/devices remain provisioned and are properly configured.
Why do you remove only the local provisioner? What is what you want to achieve? Why not deleting the whole network from that device? Or, calling
to just remove the Node? Do you want to remove the Provisioner together with the Node and synchronize it with other devices, so other also remove the Provisioner. But you'd want to do that without reinitializing any Provisioner as the new local one, right?
This seems a valid use case. I'll think about it.
As in CDB there's no indication of which provisioner is used locally, the implementation of this library uses the one at index 0. If you remove a provisioner at 0, there's a new one coming to take its place.
We could, as you suggest, not "self-heal", for example if there's a "configured" flag, etc. Or we could add a method for specific use case, like "removeFromNetwork" which would remove the local provisioner, its node and return a Data to be exported, also forgetting the whole network.
Target
Library
Describe the feature
Our application employs an internet-based synchronization mechanism to share project data across multiple devices, with each device having its own designated provisioner within the network.
Upon implementing this, we encountered an unforeseen behavior of the library as detailed below.
Unexpected behaviour
When a local provisioner is removed from the network, the data of the next available provisioner gets overridden as can be seen in MeshNetwork+Provisioner.swift.
In our scenario, this causes an issue when a user removes the device at hand from the network,
while other provisioners/devices remain provisioned and are properly configured.
So no "self-healing" would be required.
However, if such changes were synchronized, it would result in overriding the provisioner data of another smartphone.
Proposed solution
We kindly suggest the removal of the self-healing mechanism within the library. Instead, we propose that developers using the library should provide alerts to end users, guiding them to avoid potential misconfigurations or erroneous actions. This way, the responsibility of ensuring proper network configurations would be shifted away from the library and no guessing about developer's intentions would be needed.
The text was updated successfully, but these errors were encountered: