mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2016-09-08 12:24:20 -04:00
parent 442558aecf
commit 079c5a03c6
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
2 changed files with 24 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

10
doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment
View file

@ -62,14 +62,4 @@ That's not a lot more verbose than the earlier version, and it ensures that
consumers of the progress objects have all possible information available consumers of the progress objects have all possible information available
(including the name of the remote being downloaded from in the above (including the name of the remote being downloaded from in the above
example). example).
Less verbose version:
{"progress-id":"1","action":{"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1..."}}
{"progress-id":"1","percent-progress":"25%","byte-progress":500}
{"progress-id":"1","percent-progress":"75%","byte-progress":1500}
{"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1...","success":true}
Makes the consumer's job a bit more complicated, and could also make the
implementation in git-annex harder. Is it worth it?
"""]] """]]

24
doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_3_613636dabfaaeee187f54923437d89ac._comment Normal file
View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2016-09-08T16:20:27Z"
content="""
Needing to use file-level locking etc does make the mult-process approach
to parallelism more expensive, but only I think by a small amount.
Yes, there might need to be a switch to enable the json progress output.
Although given the un-typed nature of json, consumers should probably be
written with a plan in mind for what to do if they encounter something they
don't understand. Any comsumer that just skips over unrecognised json
objects would not be impacted by adding the progress..
And here's a way to make the progress json less verbose:
{"progress-id":"1","action":{"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1..."}}
{"progress-id":"1","percent-progress":"25%","byte-progress":500}
{"progress-id":"1","percent-progress":"75%","byte-progress":1500}
{"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1...","success":true}
Makes the consumer's job a bit more complicated, and could also make the
implementation in git-annex harder. Is it worth it?
"""]]