Userscripts.org

Hi, what is the best userscripts updater script? Thank you in advance!

For including in your own script or for notifying your installed scripts?

I nominate:
for including: US_update
for notifying: Userscripts Updater

To jerone: Okay, given that you've nominated your own script, I'll nominate mine. :-)

To kristof: I don't think you're going to get a definitive answer to this - everyone has their own preferences.

lazyttrick's Userscripts Updater works even for scripts whose authors did nothing to accommodate updating (other than to put the script on us.o), but needs end users to take it upon their own initiative to install and configure the updater script.

My own SelfUpdaterExample needs zero additional effort on the part of the end user to work, but needs the programmer to copy its code into any script needing updating.

jerone's US_update takes a middle ground - scriptwrights need to be aware of it and call its functions, but end users also need to install a separate script to get its functionality.

Which approach is better for you is largely a matter of where you happen to fall on the scriptwright-script user spectrum.

very nice!
I'll study your codes to improve mine
most of my scripts check for update itself (themselves?).

Here's an example
http://userscripts.org/scripts/review/33964

To "w35l3y": Your scripts take yet another approach - using Greasemonkey's @require directive to import additional code from elsewhere.

Advantages:

Disadvantages:

Edit: I completely updated my code. All the variables are now contained within the object to prevent conflicts with the script and posted my auto-update script here.

Maybe someone objective should make list of all pros and cons for all known (and up-to-date)update scripts.

I toyed with this idea for a while and discarded it as too hackish. I use Lazytrick's Userscripts Updater and it does a decent job, but the real solution would be to get this included in Greasemonkey proper. This was composed in GM ticket #45, but that seems to have become broken, so I re-requested it just now as ticket 185, http://greasemonkey.devjavu.com/ticket/185 ... please go there and voice your opinions.

Lazytrick's updater has almost 10,000 installs ... but Alien Scum's updater has over 28,000.

Related discussion topics include:

• Updater for your scripts
• Idea for a userscripts.org new feature to help with script's update
• How can i Auto update the script
• Archived Comments @ Userscripts Updater, where I initially mentioned GM ticket #45.

To jerone:

Maybe someone objective

should make list of all pros and cons

for all known (and up-to-date) update scripts.

• GM Script Update Control by Sylvain Comte
• Userscript Auto-Update Add-in (NOT FOR INSTALL) by psycadelik
• Script Update Checker by Jarett
• AutoUpdateTest by TastyFlySoup
• User Script Updates by Richard Gibson

• Another Auto Update Script by sizzlemctwizzle
• SelfUpdaterExample by yours truly
• Userscripts Updater by lazyttrick
• aaad_US_update by jerone
• Script Updater by alien_scum
• checkForUpdate within http://gm.wesley.eti.br/gm_default.js, by w35l3y (not hosted here, but used by scripts that are)

To khopesh:

Alien Scum's updater has over 28,000

If you find that meaningful, you should know that Gibson's updater has over 200,000.

Poorly written updaters will download scripts to see if an update is needed ... unfortunately, such downloads count as installs. A number like 200,000 probably includes update checks for already-installed instances. I wouldn't be surprised if Alien Scum's updater has the same flaw. Since I use lazytrick's updater, I could verify that that one does not contain this flaw (though perhaps it once did).

The same flaw, this time in self-updating scripts, is likely the culprit for a good number of the impossibly high install counts for some scripts on this site. (Though I'd imagine many of those counts were inflated though other means for fun and/or profit.)

I wouldn't be surprised if Alien Scum's updater has the same flaw.

I believe it doesn't and never has. As I recall Alien Scum made it for that exact reason. I've not used that script in quite a while though; it used to work really well but then I think the latest update broke it for me.

I personally don't actually use any script updaters any more; seeing how many there are on offer though, maybe I should consider it. Quite often I favourite the most useful scripts and take an if it ain't broke, don't fix it approach to the rest.

Poorly written updaters will download scripts to see if an update is needed ... unfortunately, such downloads count as installs.

I don't think that after 1 1/2 years Alien's script will be ever updated.
I once toke a stab at it, got very far, but lost interest. Maybe some day.

I don't know if poorly written is the right word for calling http://userscripts.org/scripts/source/'+scr_id+'.user.js
instead of http://userscripts.org/scripts/review/'+scr_id+'?format=txt when checking for updates. It's just more of an oversight.

@sizzlemctwizzle,

That syntax is better as it doesn't trip over the install counter, but you need only examine the "last updated" date stamp. Saves bandwidth, processing, etc.

@khopesh
That's a really good idea! I might incorporate that into my next update, but I don't know of any script updater that uses that method currently. I did however update my code so that it is all contained with in an object. This should prevent any variable naming conflicts with the script it is include within.

To khopesh:

you need only examine the "last updated" date stamp

This won't deal with that, either, but FYI, when I was developing my script, Jesse added URLs of the form /scripts/source/#####.meta.js just for this purpose - read all about it.

The ideal situation would be to just send a HEAD request and look at the date in the response, but I remember looking into this as a possibility when I was writing my script, and it doesn't work here since all the pages are built on the fly.

Thank you so much scrooge! That is so awesome! I've already updated my script to use just the metadata. How come this isn't like in a FAQ or something? Can you use the last-updated method for the http://userscripts.org/scripts/source/####.meta.js file? Jesse should make a file like http://userscripts.org/scripts/source/####.timestamp.txt that will give you the unix time stamp of the latest version of a script. I know its stored. Its already on the script page.

Just deployed that meta.js has the internal script id and version id.

I can add uso:updated (timestamp) if that would help. Version IDs are NEVER reused and always increase

I'm liking the @uso:version because that will work for all scripts and will take the hassle of having to change the version number manually for every update. What I would really like would be if you could set the last-update value in the response header of meta.js so I don't even have to parse the file at all. I know you can do that in PHP. I'm sure it can be done in rails too. I just don't know if it would interfere with your caching system.

sizzlemctwizzle, we will have to keep changing the version number manually because @uso:* only works in *.meta.js
*.user.js doesn't change anything

i think this is a good ideia but i don't think these @uso:* headers will change something.

@w3513y
You have a valid point. Since @uso:version only changes once a script is updated a local script has no way of knowing which version of the script is installed. @uso headers need to be placed in the http://userscripts.org/scripts/source/####.user.js file for this to be helpful. I did email Jesse and he has agreed to set the last-update value in the response header to the actual timestamp of when the script was last updated. That way we will only have to parse the script for the version number if the timestamp is different from the value we've stored.

Thanks for the meta.js, Jesse.
The updater now uses the version info provided there. It generates way less traffic, running faster too.

... we will only have to parse the script for the version number if the timestamp is different from the value we've stored.

stored where ?
js doesn't allows us to access metadata of a file (create time, last access, last modified, chmod, ...)
unless you're talking about storing it in GM header.
at least i prefer changing 1.0.0 to 1.0.1 than changing 22:19:32 12-05-2008 to 09:12:40 12-21-2008 (just some examples)

the idea is very good but let's imagine the timezone of userscript.org is different from the scripter.
not to mention daylight saving time.
i think this would be a headache.

imagine the timezone of userscript.org is different

1. Scriptwright uploads v1.2.3 of Script X on 2008/11/23 04:56:07. He (or us.o) tags this version of the script with that timestamp.
2. The script checks "now" (as the PC sees it) on the first run and records that for future reference.
3. On future runs, the script compares the current "now" to the old "now" previously recorded, and if sufficient time has passed between them, it runs an update check.
4. Meanwhile, scriptwright uploads v1.2.4 of the script; it gets tagged with 2008/12/03 23:34:45 as its timestamp.
5. Next update check, the version of the script that's running comes here looking to see which version is here, compares the 2008/12/03 23:34:45 it finds here with the 2008/11/23 04:56:07 tag embedded within itself, and concludes that a newer version exists. Both values come from (different versions of) the script itself, so, as long as the same method of calculating timestamps was used in both versions, timezones, DST, the meaning of "now" and who's defining that, etc. all make no difference.

If this seems to contradict my earlier statement that using a HEAD request would be easiest, it doesn't - so long as us.o's mechanism to ensure that this timestamp reflects the script's upload time also adds that same timestamp in the script text in a manner that makes it accessible to the script itself. OTOH, by making us.o responsible for managing the timestamping (or versioning or whatever), you end up with an update mechanism that only works for scripts hosted here on us.o. (Nothing against Jesse, but there are people who choose to host their scripts elsewhere, and it'd be nice to have the update function acknowledge and permit that.)

First of all a few hours difference matters little if you're only checking for updates every once in a while. It requires far little accuracy since the most you could be off is a day. Second, we aren't comparing the last updated value with the time on the machine so timezones don't matter anyway. We are just using it so we don't have to parse the script if the last updated value remains the same. As a method of storage I was talking about GM_setValue. ScroogeMcPump's process is a lot like mine, but I was thinking something like:

1. User installs a version of the script.
2. User runs the script the first time and it checks the Us.o to makes sure it has the current version by parsing the remote file. If it doesn't have the most current version it will prompt the user to update. Otherwise it will record the new last updated value in the header and the current time.
3. After a defined amount of time has past the script will call the server and compare the last updated value of the remote version with the one on file. If they differ then it will parse the script to see if the version has changed. If it has changed then it will prompt user to update. If not then it will store the new last updated value and the current time. If the last updated value hasn't changed it will just record the current time.

@Scrooge: You have to make sure when the first time the script runs that the version is indeed what we have installed since a user is not guaranteed to run it right after they install.