Draft
Conversation
…all configuration enum types
38f4a30 to
b255739
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@JayceFayne Hi, I am in the process of adding support for the Syncthing REST configuration part, and would like to hear your opinion about if this PR is the right way to extend the Client API based on what you've intended.
The code below is yet untested with an actual Syncthing service but the test cases should cover most details and should be something we can build on.
I plan to use the client as a tool to apply / re-apply our specific Syncthing configuration across multiple production servers (and yes, we considered to just modify the underlying XML configuration files, but this felt rather crude, so I decided to see how far we get utilizing the REST API). Long term plan is to create a client that applies the desired state principle.
Details:
Option<>initially, but decided against it for simplicity and to see if we can get around that. This requires clients to pull default configurations when they want to create folders, makesPATCHbased on the serialization types impossible, and also puts some constraints on the minimum version of the Syncthing REST API we can use (and perhaps even breaks future updates depending on how the Syncthing team keeps backward compatibility).Client:sendanddeleteand changedrequesta little to remove repetitive code. This is not yet completely fleshed out and might change.The next step is to actually use the Client to apply a concrete configuration and see how that turns out.