[New: openFATE 318085] Yast2 Bad Connection Download Improvement
Feature added by: John Banister (jbanister) Feature #318085, revision 1 Title: Yast2 Bad Connection Download Improvement openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: John Banister (jbanister) Partner organization: openSUSE.org Description: As I type this, my other computer has been attempting to perform a software update. The patch download will get to some random percentage, usually between 70 and 85, freeze, and restart. This happens over and over. As my poor 3G data connection is metered, this is both frustrating and expensive. I assume the freezing happens because either my computer or the server didn't hear the other, and both are waiting for the other to speak. I have a couple suggestions. One suggestion is to have Yast count the number of attempts at the current download and if the count is more than two, switch into a "bad connection mode." Another suggestion is that in "bad connection mode," route the download attempt through the Opera Turbo servers. They seem to be good at talking to computers that have a bad connection. Another suggestion is, in "bad connection mode" give the download protocol extra consideration that, the reason there's been no data coming in for a while is that your request to continue (or confirmation of data received) didn't make it back to the server, and repeat the request. When the transfer starts over just fine, something is happening correctly that ought to also happen in the middle of the transfer to correct the situation when it freezes. Another suggestion is that when a download freezes in "bad connection mode" (or when the file size is greater than 20 MB), in addition to "retry," provide a "resume" option that performs a check to see that the file being downloaded hasn't been updated, and if not, then (unless it's very small) resumes where it left off instead of starting over. The Firefox plugin, DownThemAll, is good at this, and it's open source, so you could copy what they do. A final suggestion is when there's an Abort in "bad connection mode" to give an option for Yast to keep the downloaded material and the list of material to download for a while, against the possibility of another installation attempt. That way stuff that was downloaded before the user ran out of time or otherwise gave up doesn't have to be re-downloaded later on. I know, "Keep Downloaded Packages" is a solution to this, but this would be "Keep Downloaded Packages that didn't install yet." Ok, thanks for taking the time to read and consider these words. They've been repeating in my mind for a few months, so I thought I might express them. Business case (Partner benefit): openSUSE.org: We want this to show kindness to people with poor, slow data connections and also to give an impression of improved reliability, which gives people a good feeling about the product. -- openSUSE Feature: https://features.opensuse.org/318085
Feature changed by: John Banister (jbanister) Feature #318085, revision 2 Title: Yast2 Bad Connection Download Improvement openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: John Banister (jbanister) Partner organization: openSUSE.org Description: As I type this, my other computer has been attempting to perform a software update. The patch download will get to some random percentage, usually between 70 and 85, freeze, and restart. This happens over and over. As my poor 3G data connection is metered, this is both frustrating and expensive. I assume the freezing happens because either my computer or the server didn't hear the other, and both are waiting - for the other to speak. I have a couple suggestions. One suggestion is - to have Yast count the number of attempts at the current download and - if the count is more than two, switch into a "bad connection mode." + for the other to speak. I have a few suggestions. + One suggestion is to have Yast count the number of attempts at the + current download and if the count is more than two, switch into a "bad + connection mode." Another suggestion is that in "bad connection mode," route the download attempt through the Opera Turbo servers. They seem to be good at - talking to computers that have a bad connection. Another suggestion is, - in "bad connection mode" give the download protocol extra consideration - that, the reason there's been no data coming in for a while is that - your request to continue (or confirmation of data received) didn't make - it back to the server, and repeat the request. When the transfer starts - over just fine, something is happening correctly that ought to also - happen in the middle of the transfer to correct the situation when it - freezes. Another suggestion is that when a download freezes in "bad - connection mode" (or when the file size is greater than 20 MB), in - addition to "retry," provide a "resume" option that performs a check to - see that the file being downloaded hasn't been updated, and if not, - then (unless it's very small) resumes where it left off instead of - starting over. The Firefox plugin, DownThemAll, is good at this, and - it's open source, so you could copy what they do. A final suggestion is - when there's an Abort in "bad connection mode" to give an option for - Yast to keep the downloaded material and the list of material to - download for a while, against the possibility of another installation - attempt. That way stuff that was downloaded before the user ran out of - time or otherwise gave up doesn't have to be re-downloaded later on. I - know, "Keep Downloaded Packages" is a solution to this, but this would - be "Keep Downloaded Packages that didn't install yet." Ok, thanks for - taking the time to read and consider these words. They've been - repeating in my mind for a few months, so I thought I might express - them. + talking to computers that have a bad connection. + Another suggestion is, in "bad connection mode" give the download + protocol extra consideration that, the reason there's been no data + coming in for a while is that your request to continue (or confirmation + of data received) didn't make it back to the server, and repeat the + request. When the transfer starts over just fine, something is + happening correctly that ought to also happen in the middle of the + transfer to correct the situation when it freezes. + Another suggestion is that when a download freezes in "bad connection + mode" (or when the file size is greater than 20 MB), in addition to + "retry," provide a "resume" option that performs a check to see that + the file being downloaded hasn't been updated, and if not, then (unless + it's very small) resumes where it left off instead of starting over. + The Firefox plugin, DownThemAll, is good at this, and it's open source, + so you could copy what they do. + A final suggestion is when there's an Abort in "bad connection mode" to + give an option for Yast to keep the downloaded material and the list of + material to download for a while, against the possibility of another + installation attempt. That way stuff that was downloaded before the + user ran out of time or otherwise gave up doesn't have to be re- + downloaded later on. I know, "Keep Downloaded Packages" is a solution + to this, but this would be "Keep Downloaded Packages that didn't + install yet." + Ok, thanks for taking the time to read and consider these words. + They've been repeating in my mind for a few months, so I thought I + might express them. Business case (Partner benefit): openSUSE.org: We want this to show kindness to people with poor, slow data connections and also to give an impression of improved reliability, which gives people a good feeling about the product. -- openSUSE Feature: https://features.opensuse.org/318085
Feature changed by: Karl Cheng (qantas94heavy) Feature #318085, revision 4 Title: Yast2 Bad Connection Download Improvement - openSUSE Distribution: Unconfirmed + openSUSE Distribution: Duplicate of #310175 + Master status: Evaluation by engineering manager Priority Requester: Desirable Requested by: John Banister (jbanister) Partner organization: openSUSE.org Description: As I type this, my other computer has been attempting to perform a software update. The patch download will get to some random percentage, usually between 70 and 85, freeze, and restart. This happens over and over. As my poor 3G data connection is metered, this is both frustrating and expensive. I assume the freezing happens because either my computer or the server didn't hear the other, and both are waiting for the other to speak. I have a few suggestions. One suggestion is to have Yast count the number of attempts at the current download and if the count is more than two, switch into a "bad connection mode." Another suggestion is that in "bad connection mode," route the download attempt through the Opera Turbo servers. They seem to be good at talking to computers that have a bad connection. Another suggestion is, in "bad connection mode" give the download protocol extra consideration that, the reason there's been no data coming in for a while is that your request to continue (or confirmation of data received) didn't make it back to the server, and repeat the request. When the transfer starts over just fine, something is happening correctly that ought to also happen in the middle of the transfer to correct the situation when it freezes. Another suggestion is that when a download freezes in "bad connection mode" (or when the file size is greater than 20 MB), in addition to "retry," provide a "resume" option that performs a check to see that the file being downloaded hasn't been updated, and if not, then (unless it's very small) resumes where it left off instead of starting over. The Firefox plugin, DownThemAll, is good at this, and it's open source, so you could copy what they do. A final suggestion is when there's an Abort in "bad connection mode" to give an option for Yast to keep the downloaded material and the list of material to download for a while, against the possibility of another installation attempt. That way stuff that was downloaded before the user ran out of time or otherwise gave up doesn't have to be re- downloaded later on. I know, "Keep Downloaded Packages" is a solution to this, but this would be "Keep Downloaded Packages that didn't install yet." Ok, thanks for taking the time to read and consider these words. They've been repeating in my mind for a few months, so I thought I might express them. + Relations: + - (feature/duplicate: 310175) Business case (Partner benefit): openSUSE.org: We want this to show kindness to people with poor, slow data connections and also to give an impression of improved reliability, which gives people a good feeling about the product. -- openSUSE Feature: https://features.opensuse.org/318085
participants (1)
-
fate_noreply@suse.de