Related is todo/some way to get a list of options for a special remote of a given type .
At the moment there is no checks in place even for built-in special remotes on either provided special remote options/parameters are not mystyped, and either values of type bool are in correct form (true/false and not on/off etc)? E.g.
(git-annex)hopa:~datalad/datalad/najafi-2018-nwb[git-annex]git
$> git annex initremote datasets.datalad.org4 location=http://datasets.datalad.org/labs/churchland/najafi-2018-nwb/.git type=git mumbojumbo=crap autoenable=ofcause
initremote datasets.datalad.org4 ok
(recording state in git...)
proceeds just fine although one of the options is not anything that special remote would care about, and a bool value for a known one is incorrectly specified (I often missed trailing e in true)
At least for the built in special remotes (not external) this should be possible and would help to avoid issues such as OpenNeuroOrg/datalad-service/issues/67 etc. Ideally parameters verification should also be provisioned in external special remotes protocol.
There's a subtle backwards compatibility issue here: The stored config of a special remote is used when enabling it, so if an older version of git-annex is used to enable a remote, there might be a setting that it does not know about, or a value it doesn't understand. If that caused it to fail to enable the remote it wouldn't be possible to use it, at least w/o changing/removing the config.
For example, autoenable=true did not used to be a config setting, but older versions of git-annex can still use remotes that have that.
Another example is chunk=. While older versions of git-annex don't understand that, and so won't use chunks when storing/retrieving, the newer git-annex falls back to getting the unchunked object. So things stored by the old git-annex can be retrieved by the new, but not vice-versa.
Another example is S3's storageclass=. Older git-annex doesn't understand it, so uses the default storage class, but that behavior is interoperable with the new behavior.
So the stored config of a remote should not be checked everytime the remote is instantiated, but only the new settings passed to initremote/enableremote. That will complicate the API, since currently the old and new config are combined together by enableremote.
I was thinking about implementing this today, but the shattered attack got in the way. Anyway, it seems like most of a plan:
Having a method return a list of fields will also allow implementing https://git-annex.branchable.com/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/. It may be worthwhile to add, along with the field name, a human readable description of its value.
Unknown fields will now result in an error message. And values like yes/no and true/false get parsed upfront.
External special remotes currently still accept all fields, so work still needs to be done to extend the protocol to list acceptable fields.
Added LISTCONFIGS to external special remote protocol, and once your special remotes implement it, initremote will notice if the user provides any setting with the wrong name.
(external special remotes could already verify the values of settings using GETCONFIG at the INITREMOTE stage, and use INITREMOTE-FAILURE to inform the user of bad or missing values)