Need better download progress signals API

I looked a bit into this, I suppose the new signals would be in addition of what is already there so signal upload and download progress?

Samuele: yes, in addition to the existing ones, unless those are not used at all by anybody.

libubuntuone at least is not using them but doing polling which the issue, though I think a start and finished event would be needed anyway.

No, libu1 doesn't use them, I meant if they are used somewhere else, like (just remembered) the nautilus plugin. So, yeah, keep them

I don't think this would be going into Lucid? It requires new API, and we are WAY past Feature Freeze now (release is in a few hours), so I'm setting this to medium.

Having fine grained status update signals is going to make for a much noisier dbus, as well. There's already the Event API dbus_interface, which can probably be listened to for fine-grained events like this for now. Is there any reason libu1 can't use that, for the time being?

even if they are not added to the status dbus interface, there are no internal events (to acces with the Events API) at all corresponding to download progress right now, what kind of granularity they should have is a different matter

Rodney, you mean com.ubuntuone.SyncDaemon.Events interface? If so, what kind of information does it send in the events? We need a good progress reporting of downloads, so that we can update a progress bar live while the download is in progress, so if the Events API can be used for that, I'm ok with that.

Of course, giving almost up to the second (between 1 and 5s) download progress is indeed going to increase dbus traffic

the linked branch contains the minimal changes to get file download progress events over com.ubuntuone.SyncDaemon.Events,
they could also be easily turned into their specifc Status signals.

How chatty is too chatty here, it is probably easy to control how many events one should get per file if needed.

Beyond if this goes to Lucid or not, we're needing this. After this is coded, it may go back to Lucid, and will not break anything (just two new signals).

This will make a noisier DBus yes, but if we don't have this, people will start to poll the syncdaemon for updates (Rhythmbox already polls it).

So, it's better to have a DBus signal propagated that 1, 2, or more processes polling for news.

OTOH, Samuele, you can just send the signal after a relevant change... you should want to know how a upload or download is progressing if the file is big, so issuing a signal only if changed a big block like 64KB, not each time a kilobyte is sent or received (note that I don't know now the granularity of action queue's queues here).

the implementation branch for Download/UploadFileProgress signals is ready to go through review to get some feedback

The branch with the implementation has been merged to the client trunk