From 0a4871cb65bb67297fff69cde81d2b2a41c6493b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 16 Sep 2022 12:39:43 -0400 Subject: [PATCH] comment --- ..._993ed66935c0d95488751a0e0e2c57b8._comment | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_7_993ed66935c0d95488751a0e0e2c57b8._comment diff --git a/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_7_993ed66935c0d95488751a0e0e2c57b8._comment b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_7_993ed66935c0d95488751a0e0e2c57b8._comment new file mode 100644 index 0000000000..df432c53ca --- /dev/null +++ b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_7_993ed66935c0d95488751a0e0e2c57b8._comment @@ -0,0 +1,23 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 7""" + date="2022-09-16T16:27:58Z" + content=""" +> I'm not sure if there are use-cases where this additional information is useful to the remote + +It would be useful when the actions transfer content, since the remote +could look at the key sizes and accumulate a reasonable amount of data +for it to handle in one operation. + +>> This is more complicated + +By that I meant, it's more complicated for the poor author of the external +special remote, who has to learn about the async protocol. + +But not using the async protocol will always have the problem I discussed +in comment #5, since the implementation in git-annex is always +to send a command like REMOVE and wait for a response like REMOVE-SUCCESS. +Using the async protocol lets it keep that implementation simple, by +multiplexing the multiple removes into different jobs, which when +demultiplexed look the same as a single remove looks now. +"""]]