add DEBUG

doc/design/external_backend_protocol.mdwn

@@ -122,6 +122,9 @@ This is where work happens.
 
 These messages can be sent at any time by either git-annex or the program.
 
+* `DEBUG message`  
+  Tells git-annex to display the message if --debug is enabled.  
+  (git-annex does not send a reply to this message.)
 * `ERROR ErrorMsg`  
   Generic error. Can be sent at any time if things get too messed up to
   continue. When possible, use a more specific reply.  

doc/design/external_special_remote_protocol.mdwn

@@ -378,7 +378,7 @@ handling a request.
   may be empty to get all urls.
   (git-annex replies one or more times with VALUE for each url.
   The final VALUE has an empty value, indicating the end of the url list.)
-* `DEBUG message`
+* `DEBUG message`  
   Tells git-annex to display the message if --debug is enabled.  
   (git-annex does not send a reply to this message.)
 

doc/todo/external_backends/comment_14_6edc4008ce8eec17e283dd7db8dbcbf0._comment

@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2020-07-27T15:20:00Z"
+ content="""
+> What is the advantage of a separate VERIFYCONTENT request, vs calling
+> GENKEY and comparing the result?
+
+Nothing for remotes using a hash. However, if the remote is using something
+other than a hash, or a hash combined with something else, it might not be
+able to regenerate the same key. It may still be able to detect
+corrupted content, eg using the hash part of the key.
+
+> Can the protocol specify that the file passed to GENKEY may be a named pipe
+
+I can't think of any situation where git-annex would GENKEY before
+it has the full content of a file available.
+
+> add DEBUG and INFO requests
+
+For INFO I'd rather wait for a use case. None of the current backends ever
+need to display any messages, except for in the case of an exceptional error,
+eg a hardware faulure where hashing. And ERROR would be fine for that.
+
+DEBUG sure.
+"""]]