GNU bug report logs - #75959
[PATCH] (home-)syncthing-service: added support for config serialization

Previous Next

Full log

View this message in rfc822 format

From: Zacchaeus <eikcaz <at> zacchae.us>
To: 75959 <at> debbugs.gnu.org
Subject: [bug#75959] [PATCH] (home-)syncthing-service: added support for config serialization
Date: Sat, 01 Feb 2025 03:58:48 -0500

Hi Guix!


In order to test my implementation, I compared two pairs of configs:

 - the default config generated by syncthing with the default config
   generated by (syncthing-configuration (syncthing-config-file
   (syncthing-config-file))).

 - my syncthing-gui-generated config with the config generated by a
   syncthing-config-file reflecting my (rather complex) setup.

There are a few differences:

 - The core differences hinge around the fact that the current device ID
   is not known in advance.  Of course, if you have already run
   syncthing and know your device ID, you can specify that in your
   config.

   - The default ~/Sync folder normally includes the current device.
     The documentaiton makes it clear that this is OK (and also I have
     tested this).

   - The config does not include the current device.  The documentation
     says "One or more device elements must be present in the file", but
     it seems to work fine dispite this.

   - The default folder template normally includes the current device.
     Also fine.

 - There are also three miscelaneous differences:

   - The default device template normally omits the "name" field.  I
     suppose I could have added code to fix this, but I know it doesn't
     break anything so I opted for slightly simpler code.

   - The API key doesn't match.  Of course it doesn't.

   - The ~/Sync folder is normally specified by /home/<user>/Sync, but
     since I know ~/Sync works, I found that better than trying to
     compute ~/ in scheme.
   
In summary, there are differences, but those differences have been
accounted for and don't introduce bugs.  There were a few undocumented
behaviors around the absense or presense of a value.  In such cases, I
implemented whatever behavior was observed in a config file maintained
by the Syncthing GUI.

I considered submitting this as two patches, one for the home service
and one for the system service, but patching just the system service
broke the home service.  Is that a valid reason to make it one patch?
If not, I can split up the patches and resubmit.

Addressing the elephant in the room, as I mentioned in the
documentation, I used camelCase only to match syncthing documentation.
For instance, the ldap searchFilter setting is configured by
(syncthing-config-file (ldap-searchFilter "...")).  As nauseous as it
made me to write something like that, I think translating names to
snake-case adds too much confusion/complexity no matter where you add
it.  It is useful when refencencing Syncthing documentation to know
exactly what keyword too look for.  Though I believe exceptions exist to
every rule, and that this is maybe the only ecxeption to the no
camelcase rule, please do tell me if there is a better way and I will
resubmit the patch.


eikcaz-

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.