Opened 3 years ago
Closed 3 years ago
#21634 closed enhancement (wontfix)
[PATCH] Download Along: Allow user to configure if there's a confirmation dialog for small number of download requests.
| Reported by: | Owned by: | team | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Core | Version: | latest |
| Keywords: | Cc: |
Description
DownloadAlong will ask the user to confirm if it wants to make more than 1 download request. With this patch, the user can set a preference (downloadAlongWay.numDownloadRequestConfirmation or downloadAlongTrack.numDownloadRequestConfirmation), and JOSM will not ask for confirmation if it would make less than or equal to this many requests. If this preference isn't set, it's assumed to be 1. i.e. JOSM will require confirmation when it would make more than 1 request, which is the current behaviour.
I made this patch because I don't want the extra step for making (e.g.) 5 requests.
This patch is against svn r18327. Please feel free to review it and give feedback. I'm not very experienced with java.
Attachments (1)
Change History (4)
by , 3 years ago
| Attachment: | download-along-less-confirmations.patch added |
|---|
comment:1 by , 3 years ago
I fear that's not a good idea. This dialog is also there to remember the user that he puts a lot of load to the server. Making that configurable somehow isn't the best idea for this purpose.
comment:2 by , 3 years ago
@stoecker: Did you intend to close this as WONTFIX?
@Amanda McCann:
As far as the patch goes (using the version on GitHub), I don't see anything glaringly wrong. The one caveat is that I would add @since xxx for any changed method signatures, keep the old method signatures by calling the new ones with the original values, and deprecate the old versions. This is mostly so that we give plugins some time to fix stuff, if they are using that code.
With that said, I am inclined to agree with stoecker that this is a bad idea for the default OSM API (some people will do stupid things, and ruin editing for everyone else -- I don't know about you, but I've seen some instances recently where the OSM API was overloaded).
You could put a max limit on it (i.e., Math.min(Math.max(number, 1), 3)), but someone would have to figure out what the max should be. Something low, like 3.
EDIT: GitHub PR: https://github.com/JOSM/josm/pull/84
comment:3 by , 3 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
@amanda: I'm sorry that I'm closing this as WONTFIX, but I really don't think we can justify adding to the load on the OSM API servers, especially when it seems to have problems every few months.
With that said, I'm open to changing my mind if one of the server admins comes along and tells us that the OSM API servers can handle the extra load and what they think the absolute max should be.
patch against r18327