apport should be mini-ftp client with resuming capabilities

[Shirish Agarwal]

Binary package hint: apport

apport should be like a mini-ftp client having a nice interface having the following features :-
 1. It should have a progress bar https://bugs.launchpad.net/ubuntu/+source/apport/+bug/91521
 2. It should have count of the speed at which it is uploading with an ETA of completion.
 3. If for some reason network failure, computer shut-down etc. it should resume from where it stopped.
           I guess some kind of hash checks along the way and some things would have to be improved on the mirror.
        Idea shamelessly lifted from bittorrent.
 4. If there are errors, either it should display to the user the errors or maintain a log of errors which it can try to upload
     or the user can upload it.
 5. It should try to see if /var/crash is empty or not. If /var/crash is not empty that means a report has not been sent,
     it should try re-sending it and if it fails ask user to take some action.

         That is all on the top of my head. :)

[Scott Kitterman (kitterman)]

This is a significant enough design change that it should be re-written as a spec, given broad review, and approved or rejected.

See https://wiki.ubuntu.com/FeatureSpecifications for how to submit.

[Shirish Agarwal (shirishag75)]

Well, I made the same thing at https://blueprints.launchpad.net/apport/+spec/shirish

[Paul van Genderen (paulvg)]

None of that user interaction, please. Atleast not by default. A bug already disrupts the normal workflow, and bothering the user with a mini-ftp client just makes a bad situation worse. I'd rather have the reports be sent in the background, and if it fails, it shouldn't disrupt the workflow /again/. I mean, to the user that would look like a bug in a bug.

So instead, it would be cool if there's a notification area icon when a bug report is being sent. If the user is inclined to know about the progress, simply by clicking the icon a progress meter appears. The count of speed to the average user is just moot, estimated time of completion makes sense if it takes more then a couple of minutes. If that's normal, then by all means include it. Another report could be put in the queue while it's sending (and again and again), and it wouldn't mean having lots of progress dialogs all over the place (I have a screenshot somewhere of Windows XP with a screen full of such dialogs).

And why ever bothering the user if it fails to send reports that the user might already have forgotten about anyway? Chances are that by the time apport finds out the network isn't properly functioning, the user already knows it (maybe NetworkManager already pointed it out for instance). IMHO the notification icon should then just stay there, and when the user clicks it, an option is given to retry, ignore them (until reboot), or just delete them.

Remember that unwanted OS interaction is always bad, and gets in the way of actually doing things. Except for some who actually enjoy to see things break because it means that they have an opportunity to fix something (myself included), but thats a minority.

I don't use Python much, but I'd be glad to help with the implementation of this. Notification icons seem to be possible with pygtk and pyQt, and notification bubbles with python-notify.

[Shirish Agarwal (shirishag75)]

Although I do tend to agree that it should not be by default, but it would be cool for the user who is interested in the bug-report.
            Lets take the case of user case A whose application keeps on failing, some x buggy program, so by default apport would be sending but the user never comes to know that the report never got sent due to some error or the other.
             User B is a good citizen & religiously files the bug reports but at times he gets errors (something like 500 Internal Server after trying to actually send the bug report for 30 mins.) He does not know the reason why it happened. He then takes recourse of servers like rapidshare.com but that is insecure, prone to more failure (no way to do some parity-checking) or something like that.

              Reference bug #103604 for use-case scenario B.

             Point to be noted :- The crash file therein is only 7 MB, I am on 246 Kbps/64 Kbps unlimited connection. Tried sending the bug-report at the very least 5-6 times without no result. Once after 2 hrs. of apport saying it is uploading I get an Internal Server Error 500. At the end, had to take recourse of rapidshare.com twice but without any positive outcome (some parity issue or some other thing probably). User having -1 experience with the whole bug-reporting experiencing with apport.

            Further as we move to feisty+1 or even a bigger bug-report lets say an openoffice crash (maybe 15-20 MB) reasonable , shudder to think how I would do it under the present circumstances.

[Paul van Genderen (paulvg)]

A notification bubble could inform that it failed to send the report. Good citizens would click it and try to do something about it, others would just ignore it or promptly close it and get on with things.

Also, new reports should be inserted at the top of the queue, because they happened more recently and thus should be regarded a bit more important.

With reports being a heavy 20MB, yes, an ETA is a very good idea.

[Shirish Agarwal (shirishag75)]

While chatting on IRC couple of people did inform that they were successful on sending 50 MB crash files. Mind you these are the full crash reports, not the shrinked down version as apport also gives as an option. Users who are fanatic or fan of some software, for e.g. blender, OpenOffice.org or something like that would try sending the full report, as they would want the issues to be fixed in their favorite distribution Ubuntu. Also perhaps I should have worded my wordings more, it should behave (back-end) lke a mini-ftp client but for the user give a simplistic outlook.

[Shirish Agarwal (shirishag75)]

 I came to know that apport uses a library called urllib (from python) I tried to ask the same question in python newsgroups & this is the answer I got :-

http://groups.google.com/group/comp.lang.python/browse_thread/thread/f68f202456a0e47b/e633056eb37d4f34#e633056eb37d4f34

 somebody has implemented an upload progress bar :-

http://www.opensky.ca/~jdhildeb/software/kodakloader/