structured notification system is getting unwieldy

[rbtcollins]

Describe the problem you are trying to solve
We're having to generate user feedback from many narrow places in the code - such as spin-loops around rename() syscalls to deal with virus scanners - and the notification system as it currently all hooks together is quite unwieldy.

Describe the solution you'd like
I haven't thought this far ahead yet. I will. Perhaps a 'context' object of some sort that we make systematically available. I'd like to avoid creating overly strong coupling in the system. And I'd like it to be designed work with an eventual highly concurrent build where multiple tars are downloading and unpacking all at once with 4 or 5 lines of progress bar showing at once.

Notes

[kinnison]

We thought about migrating most of the notifications to a standard logging framework, but then there is the idea to move to something external to replace our progress bars, so perhaps a context which can be passed around which is a conduit to a UX thread dealing with all of that might make sense.

[rbtcollins]

Another design requirement: structured programmatic output for use from visual code and other tools.
I'm thinking of bolting a structured encoding - e.g.. protobuf- onto stdout; ok maybe protobuf is a bad choice and YAML or something less demanding of clean 8-bit channels would be better, though, waggles hand, I've been around that before with subunit and honestly biting the bullet and making it truely 8-bit clean wasn't that hard and chased bugs out of the system.