todo/assure correct names (and values) for special remotes parametersyohhttp://git-annex.branchable.com/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/git-annexikiwiki2020-06-17T01:18:32Zcomment 1http://git-annex.branchable.com/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_1_63d48db769863cdfe411404e8c26a399/joey2020-06-17T01:18:32Z2020-01-06T16:12:01Z
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
comment 2http://git-annex.branchable.com/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_2_afa8c10bd3b1df649c1f643430b300e9/joey2020-06-17T01:18:32Z2020-01-07T17:59:35Z
<p>I was thinking about implementing this today, but the shattered attack got
in the way. Anyway, it seems like most of a plan:</p>
<ul>
<li>Make RemoteConfig contain Accepted or Proposed values. enableremote and initremote
set Proposed values; Accepted values are anything read from git-annex:remote.log
(update: done)</li>
<li>When a RemoteConfig value fails to parse, it may make sense to use a
default instead when it's Accepted, and error out when it's Proposed. This could
be used when parsing foo=yes/no to avoid treating foo=true the same as
foo=no, which some things do currently do
(eg importtree, exporttree, embedcreds).
(update: Done for most yes/no and true/false parsers, surely missed a
few though, (including autoenable).)</li>
<li>Add a Remote method that returns a list of all RemoteConfig fields it
uses. This is the one part I'm not sure about, because that violates DRY.
It would be nicer to have a parser that can also generate a list of the
fields it parses.</li>
<li>Before calling Remote setup, see if there is any Proposed value in
RemoteConfig whose field is not in the list. If so, error out.</li>
<li>For external special remotes, add a LISTCONFIG message. The program
reponds with a list of all the fields it may want to later GETCONFIG.
If the program responds with UNSUPPORTED-REQUEST then it needs to return
something that says any and all fields are allowed.</li>
<li>External special remotes are responsible for parsing the content of
GETCONFIG, as they do now, and can error out if there's a problem.</li>
</ul>
<p>Having a method return a list of fields will also allow
implementing
<a href="https://git-annex.branchable.com/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/">https://git-annex.branchable.com/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/</a>.
It may be worthwhile to add, along with the field name, a human readable
description of its value.</p>
comment 3http://git-annex.branchable.com/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_3_f19ff768a3903f80dbaa378b74d2a7e3/joey2020-06-17T01:18:32Z2020-01-15T17:52:07Z
<p>Unknown fields will now result in an error message. And values like yes/no
and true/false get parsed upfront.</p>
<p>External special remotes currently still accept all fields, so work still
needs to be done to extend the protocol to list acceptable fields.</p>
comment 4http://git-annex.branchable.com/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_4_b031ee12622b1ed28b6ffc8c037f7d30/joey2020-06-17T01:18:32Z2020-01-17T21:15:16Z
<p>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.</p>
<p>(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)</p>