Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop overriding arbitrary provisioners when localProvisioner is removed #577

Open
bspinner opened this issue Oct 26, 2023 · 1 comment
Open
Labels
enhancement New feature or request

Comments

@bspinner
Copy link
Contributor

bspinner commented Oct 26, 2023

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.

@philips77
Copy link
Member

philips77 commented Oct 27, 2023

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

func disableConfigurationCapabilities(for provisioner: Provisioner) {
remove(nodeForProvisioner: provisioner)
}

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.

@philips77 philips77 added the enhancement New feature or request label Oct 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants