Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Users should be able to disable update checking, per-script #1423

Closed
arantius opened this issue Sep 23, 2011 · 8 comments
Closed

Users should be able to disable update checking, per-script #1423

arantius opened this issue Sep 23, 2011 · 8 comments
Milestone

Comments

@arantius
Copy link
Collaborator

From: #1053 (comment)

As with extensions, you should have the option to disable update checking on a per-script basis (if it hasn't already been implemented).

@arantius
Copy link
Collaborator Author

arantius commented Oct 6, 2011

But I don't see how extensions have the option to disable updating on a per-extension basis. Anyone?

@arantius
Copy link
Collaborator Author

arantius commented Oct 6, 2011

Whoops duh: in the "detail" view that you can only get to by double-clicking: the "automatic updates: default/on/off" radio buttons.

@sizzlemctwizzle
Copy link
Contributor

I say we put a "Enable/Disable Updates" option in the context menu after "Find Updates". No sense using the detail view for this since we don't use it for anything else atm.

@sizzlemctwizzle
Copy link
Contributor

I believe that the option on the detail page controls whether updates are applied automatically. I'm pretty sure that extensions always check for updates and there's no way to turn this off (unless there is some secret about:config option). Perhaps we should follow suit? What's the harm in just checking for updates? We could take the code you wrote for this issue and adapt it to turn off/on automatic updates on a per-script basis for #1442.

@arantius
Copy link
Collaborator Author

I'm pretty sure that extensions always check for updates and there's no way to turn this off

The difference from my viewpoint is that is Mozilla, writing code that affects load on Mozilla's servers. In our case we're loading someone else's servers. And mostly userscripts.org, which AFAICT already struggles with load. So I'd like to add less, where possible.

@sizzlemctwizzle
Copy link
Contributor

Since we plan on enabling update checking by default, most users probably won't take the time to turn it off or won't want it off so I doubt we would significantly decrease traffic with this feature.

I also doubt update checking will put too much of a strain on userscripts.org. The majority of its past problems were cause by poorly written update checking routines in user scripts that would download the script source page (the actual HTML page not the .user.js file) every few milliseconds. At a minimum a script can only be automatically checked for an update once a day. That is a hard coded minimum. The only way around it is to edit the source and build GM yourself.

When it comes to userscripts.org we only download the metadata of a script when checking for an update. For those who want to host scripts and keep bandwidth usage to a minimum, they can upload just the metadata (hell they could leave everything out except the @version key) to a seperate url and point to it with @updateURL.

I just don't think the small possible decrease in network traffic and bandwidth is worth the added complexity, both in terms of complicating the code and the complicating of our UI by providing the option to turn off/on automatic update checking and automatic installing of updates for each script.

@Martii
Copy link
Contributor

Martii commented Oct 22, 2011

@sizzlemctwizzle,

... most users probably won't take the time to turn it off or won't want it off...

This is probably true however taking this home... this script hasn't been updated since 2005 and still works in most situations... you'll also notice that the userid is no longer around yet the script still is... I can't attest to why the script hung around other than it does get installed and referenced in derivative scripts. In this instance I would absolutely want to turn off the automatic update check for this script since the ScriptWright has zero chance of updating the script at that scriptid.

Other scripts that I use in my favorites towards the end of the list are rarely updated as well so I typically don't rely on any update mechanism other than USOs email notification.

In general it's a good idea not to increase the traffic from the Clients perspective since data usage caps are increasing.

to a separate url and point to it with @updateURL.

I was under the impression that this wasn't supported yet... is it?

If the question/statement is "Why was this feature put in?" this is some of the reasoning why I like the availability of disabling script updates per script along with some scripts I, and many others, like to review before they are updated and put to use.

@sizzlemctwizzle
Copy link
Contributor

@Martii
Alright, I guess there are some situations where turning off update checking for a script can be useful.

I was under the impression that this wasn't supported yet... is it?
As far as I know it's already supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants