diff options
author | 2016-09-08 12:24:20 -0400 | |
---|---|---|
committer | 2016-09-08 12:24:20 -0400 | |
commit | bd35f4d6a20490304e4222b9b622c6bcd2ec3039 (patch) | |
tree | d0c710f1fd7e883357a4b1cfddeb3f2c857dbde9 /doc | |
parent | f85ad06834a7e730d0d5c9a5156412f05da8258c (diff) |
comment
Diffstat (limited to 'doc')
2 files changed, 24 insertions, 10 deletions
diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment index 2a5785bfc..df74f19cb 100644 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment +++ b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment @@ -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 (including the name of the remote being downloaded from in the above 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? """]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_3_613636dabfaaeee187f54923437d89ac._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_3_613636dabfaaeee187f54923437d89ac._comment new file mode 100644 index 000000000..33e05de54 --- /dev/null +++ b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_3_613636dabfaaeee187f54923437d89ac._comment @@ -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? +"""]] |