progress report on checkin()

[tomeu]

We need to get some kind of progress report about checkin operations.

We don't need a perfect solution neither an estimated completion time.

I propose adding a dbus signal 'CheckinProgressChanged' with uid and percent as parameters.

[tomeu]

Oh, we'll also need to pass the checkin() func the total size of the file, so the progress report can be calculated.

[marco]

Tomeu, is this a blocker?

[tomeu]

Dan Williams has implemented this in the trial3 branch. We can leave this open but retarget for FRS.

[marco]

Tomeu what is left here?

[tomeu]

After looking at the code, the async copy is not yet reporting progress. I think this would be mainly useful for copies to flash drives, as in most other cases we are just moving the file to internal storage.

What is still left to do is to update the 'progress' metadata property and emit the Updated signal after every block is copied. In this way the Journal will show a progress bar as the file is copied to the usb stick.

So basically we need to know if progress report when copying entries to usb sticks is needed for FRS.

[marco]

Implementation is not trivial and in an area where the code is not solid yet. Risk seem high. Should be prioritized on the base of the environment (are USB keys going to be very important in the field?) and on the criticality of the usability problem (design team).

My personal recommendation would be to punt this one.

[Eben]

It's clear we can't do async copies without feedback. Of course, long blocks for copies, especially without progress, will make the machine feel frozen (well, it is frozen...) and that's not a very good situation either. Both scenarios lack any useful feedback.

As such, the only real solution seems to be proper async support with progress feedback, and I think the usability concerns are high without it. I can't speak to the importance of USB in the field, though, so I can't determine criticality.