Ticket #2761 (new enhancement)

Opened 7 years ago

Last modified 6 years ago

progress report on checkin()

Reported by: tomeu Owned by: tomeu
Priority: high Milestone: Future Release
Component: sugar-datastore Version:
Keywords: Cc:
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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.

Change History

Changed 7 years ago by tomeu

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

Changed 7 years ago by marco

Tomeu, is this a blocker?

Changed 7 years ago by tomeu

  • milestone changed from Trial-3 to First Deployment, V1.0

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

Changed 7 years ago by kimquirk

  • priority changed from blocker to high

Changed 7 years ago by marco

Tomeu what is left here?

Changed 7 years ago by marco

  • milestone changed from First Deployment, V1.0 to Untriaged

Changed 7 years ago by 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.

Changed 7 years ago by 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.

Changed 7 years ago by 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.

Changed 7 years ago by jg

  • milestone changed from Untriaged to Update.2

Changed 6 years ago by marco

  • milestone changed from Update.2 to Future Release
Note: See TracTickets for help on using tickets.