From 8aa6f60fc3145814fbd4e777823c6371a006e43a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 7 Jan 2020 14:27:53 -0400 Subject: [PATCH] plan --- ..._afa8c10bd3b1df649c1f643430b300e9._comment | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_2_afa8c10bd3b1df649c1f643430b300e9._comment diff --git a/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_2_afa8c10bd3b1df649c1f643430b300e9._comment b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_2_afa8c10bd3b1df649c1f643430b300e9._comment new file mode 100644 index 0000000000..47f70e8bb8 --- /dev/null +++ b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_2_afa8c10bd3b1df649c1f643430b300e9._comment @@ -0,0 +1,34 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2020-01-07T17:59:35Z" + content=""" +I was thinking about implementing this today, but the shattered attack got +in the way. Anyway, it seems like most of a plan: + +* Make RemoteConfig contain Old or New values. enableremote and initremote + set New values; Old values are anything read from git-annex:remote.log +* When a RemoteConfig value fails to parse, it may make sense to use a + default instead when it's Old, and error out when it's New. 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). +* 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. +* Before calling Remote setup, see if there is any New value in + RemoteConfig whose field is not in the list. If so, error out. +* 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. +* External special remotes are responsible for parsing the content of + GETCONFIG, as they do now, and can error out if there's a problem. + +Having a method return a list of fields will also allow +implementing +. +It may be worthwhile to add, along with the field name, a human readable +description of its value. +"""]]