From: Joey Hess Date: Fri, 16 Sep 2022 16:39:43 +0000 (-0400) Subject: comment X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~2^2^2~47^2~110 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=0a4871cb65bb67297fff69cde81d2b2a41c6493b;p=git-annex.git 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. +"""]]