Document update logic

[JasonBarnabe]

As part of development of Greasy Fork I have support for updates via @updateURL and @installURL. I was told these weren't necessary and pointed to #1824.

To fully understand what GM is doing so I can set up my site in the optimum way, I would like GM's update logic documented somewhere. Specific questions I have are... What requests does GM make when these meta keys are defined? What requests does GM make when they're not? Is one way recommended and the other legacy? Does the behaviour differ between HTTP and HTTPS? The updateURL "need only contain the metadata block"; what happens if it has the code too? Bonus points for any information on how GM clones act.

[sizzlemctwizzle]

via @updateURL and @installURL

@installURL is not used. I think you're thinking of @downloadURL.

What requests does GM make when these meta keys are defined?

If I remember right (this could have changed), if only one of the two are set, the url is used for both checking for updates and installing an update. Otherwise their behavior is already documented.

What requests does GM make when they're not?

GM stores the url a script was installed from and uses it for both update checking and installing updates.

Is one way recommended and the other legacy?

Using both is recommended if you decide to use them at all.

Does the behaviour differ between HTTP and HTTPS?

Update checking and installing require a HTTPS url by default (you can change this in the GM settings dialog). Otherwise a script will not be checked for updates.

what happens if it has the code too?

It doesn't effect anything. The point is that the whole script doesn't need to be downloaded to check for an update, which should save you bandwidth. This idea came from userscripts.org's .meta.js files, which were added for update checking routines in user scripts before GM had an updater built-in.

[JasonBarnabe]

Thanks for the answers. I think this info would be useful to put somewhere on the wiki, as the lack of any other info on updating in Metadata Block made me believe that downloadURL and updateURL were necessary for updates.

Is one way recommended and the other legacy?

Using both is recommended if you decide to use them at all.

I didn't mean downloadURL vs updateURL, I meant specifying downloadURL and updateURL vs not specifying them.

[sizzlemctwizzle]

I meant specifying downloadURL and updateURL vs not specifying them.

It's really up to you. As long as you server up scripts on an HTTPS url, then GM will handle things automatically. Although the full source (unless you implement support for #1824) will be downloaded to check for updates. We still need to get the other user script engines to support #1824, but GM has many more users so that's not at the top of my to-do list.

[arantius]

I need to spend some time digging to make sure this is correct, but off the cuff:

• There's always a download URL. If not explicitly set, it's whatever URL the script was actually downloaded from.
• There's always an update URL. If not explicitly set, it's the download URL.
• Updates are always checked for at the update URL. We only need, thus can safely only be delivered, (a subset of, actually) the metadata. All we do is check versions really. Higher version means update is available.
• If an update is available, we always download it from the download URL.

If you don't set anything, the update URL is the download URL is the URL you actually got the script from. We'll always load that to check for updates, and we'll always load that to download new versions. This is probably good enough for the vast majority of cases.

If you set either one in your script, that only changes where we'll fetch from for each update stage (check for, actually get).

[sizzlemctwizzle]

I need to spend some time digging to make sure this is correct

It's pretty bad when neither one of us can remember for sure haha. This probably does need to be documented somewhere (probably not on the metadata page but a separate "script updates" page).

[JasonBarnabe]

Yeah, it doesn't make sense to be directly on the metadata page, except for something like a "see also" link to the new page under downloadURL and updateURL.

One further question... Is there a way to disable updates on a script from the metadata? Greasy Fork lets users see and install old versions of a script, and since they explicitly chose an old version, they will not want updates. I can handle returning the old version number each time an update check happens, but it would be better if I could indicate to GM not to bother.

[sizzlemctwizzle]

Is there a way to disable updates on a script from the metadata?

Set the @downloadurl and @updateURL values to a HTTP (or invalid, maybe) url? That's the best idea I've got.

[arantius]

One further question... Is there a way to disable updates on a script from the metadata?

Not as a designed/supported feature, but yes by workaround. I.E. as sizzle said above, or just make sure neither URL is in the metadata, and update checks will always go to this URL (which I assume links specifically to this version) which will never pass the 'has update' check.

[sizzlemctwizzle]

update checks will always go to this URL (which I assume links specifically to this version) which will never pass the 'has update' check.

Correct. And if he serves up old versions of the script over HTTP it would prevent update checks all-together, except if the user has set GM to allow updates over HTTP but in that case it would still never update as you said.

Not as a designed/supported feature

Do think adding a metakey to disable updates would be useful/desirable?

[arantius]

Do think adding a metakey to disable updates would be useful/desirable?

I have to try really hard to imagine a situation where an author is writing a script and knows for certain that it will never ever in all possible futures ever be appropriate to update the script. That leaves only machines (i.e.) patching an old version, which appears to have a perfectly valid workaround already.

[cletusc]

I would be fine with a site stripping any @-URL keys for old versions so that GM will check the URL it was installed from (which happens to be the old version of the script, so all good). This would keep it in line with other engines that do update checks. I don't think a separate meta key would/should be needed.

Maybe have that noted somewhere as a workaround for sites.

[derjanb]

We still need to get the other user script engines to support #1824, but GM has many more users so that's not at the top of my to-do list.

1,178,817 weekly Tampermonkey vs. 1,865,039 daily GM users is not a real big difference. ;)
But what I meant to say is TM version 3.7.3900 and higher now supports #1824 and

Bonus points for any information on how GM clones act.
All we do is check versions really. Higher version means update is available.

USO's metadata also has a property called "@uso:hash". At least TM checks this and updates the script when its value is different even if the script doesn't have a @Version tag.

[sizzlemctwizzle]

1,178,817 weekly Tampermonkey vs. 1,865,039 daily GM users is not a real big difference. ;)

I had no idea TM had become so popular. It's good to hear that user scripting is prevalent on Chrome. A few years ago I actually considered porting GM to Chrome (which would have been a massive undertaking), but luckily I discovered TM before I started working on it.

Now if we could just getting GM working on Fx Mobile so I could install user scripts on my phone, I'd be thrilled. Scriptish had this until Fx Mobile removed XUL, but I have to give Stylish credit for converting its manager to HTML and getting it to work. If I wasn't so busy with OpenUserJS.org I'd be working on this right now.

Btw, will TM ever download resources (@require and @resource) instead of relying on the Chrome cache (which I've been told doesn't work very well)? As someone who has hosted a popular @require on my own server, I wasn't crazy about getting pounded with hits from TM.

[derjanb]

Btw, will TM ever download resources (@require and @resource) instead of relying on the Chrome cache

In fact in addition to TM's internal cache it should already make use of Chrome's cache. I just retested this a for both @requires and @resources and I get Status Code:200 OK (from cache) at the network tab of the background console.
So maybe your server somehow thwarts Chromes cache magic? For my changelog.php I had to deliver a Last-Modified header, check If-Modified-Since and send HTTP/1.0 304 Not Modified especially to make Chrome display the cached copy. For long-life data an additional Expires header should help.

[sizzlemctwizzle]

So maybe your server somehow thwarts Chromes cache magic?

So when I eventually implement hosting of @requires for OpenUserJS.org, I'll have to configure and send all these these headers to make caching work? Seems like a lot of work when TM could just download these files at install time like GM. Is there any particular reason why TM doesn't?

[derjanb]

TM utilizes the "cloud" approach what means it assumes we have abundant network bandwidth and remote storage. Furthermore caching non-changed data is a solved problem so why not use it.
This has some advantages:

• TM doesn't need to take care of the resources, they are just retrieved with when needed
• In case a library is updated (features, fixes, security issues...) we almost instantly profit
• the resources don't have to be re-downloaded when a script is re-installed or modified

I'll have to configure and send all these these headers to make caching work?

I've double checked this, for data retrieved via XHRs only this needs to be added:
res.setHeader("Cache-Control", "public, max-age=" + (90 /* days */ * 24 * 60 * 60));

[jerone]

Updates are always checked for at the update URL. We only need, thus can safely only be delivered, (a subset of, actually) the metadata. All we do is check versions really.

Does GM checks more the only the @version from the metadata? Does it confirm the @namespace for example?
What I mean is, what is the minimal format required for the @updateURL to work?

[Ventero]

Does GM checks more the only the @Version from the metadata? Does it confirm the @namespace for example?

No, see Script#checkRemoteVersion.

What I mean is, what is the minimal format required for the @updateURL to work?

// ==UserScript==
// @version 1.2
// ==/UserScript==