|
|
I find the lack of an update scripts feature in Greasemonkey astonishing. There are some threads in the greasemonkey-dev group for this feature but they haven't reach an agreement yet. Many userscripts implements a "check for update" code, but they usually rely on external sites to check the script current version or other data I wonder if userscripts.org could provide that function. Each userscripts could have an URL like "http://userscripts.org/scripts/meta/scriptid" (for example) where the server could provide the script metadata (or only the @version header, or last update date, or something) in XML or JSON format, so the script can use XmlHttpRequest and get it easily, and display a message to the user if there's a new version What do you think? |
|
|
All you need is the Last Modified date, which this server does not set.
|
|
|
I haven't thought about using HTTP headers. It's interesting, a simple HEAD request will suffice (with a referer header to avoid the recent anti-hotlinking measures against scrap all bookmarklets). Unfortunately, Tamper Data shows that the server doesn't provide any usable header for this purpose What does cross-site XHR that GM_xmlHttpRequest can't do? |
|
|
GM_xmlHttpRequest does not send a referer header, and I was thinking of other browsers like Opera.
|
|
|
I thought that with GM_xmlHttpRequest you could sent the headers you want Anyway, let's see if the admis like the Http header idea |
|
|
You can send most headers, some are apparently ignored.
|
|
|
Any input from USO.org webmasters on this (Last Modified header or metadata XML/JSON)? I had been waiting for an answer on this before starting to write update code for my script I'd be nice to know other scriptwriters opinions on this topic, too ;-) |
|
|
How are you planning to implement it?
If the server did send an accurate Modified header - for any of the script links, it would be more reliable, but the source server can be checked and the appropriate function be used. I would not do this automatically because for one it isn't necessary to check for updates every time the script is run, and why bother storing yet another value that someone could muck up? I don't like auto updates, but that's just me, and probably everyone on dial-up. But I'm wondering what you were thinking... |
|
|
Something a bit different, but on the same topic, the big problem I have with updating scripts, is knowing what version I currently have. It's really a no-brainer to check for updates, just look in your Favorites, the difficult part is knowing when you last updated.
var helplink = document.createElement('link');
helplink.rel = "Script_name";
helplink.href = "http://userscripts.org/scripts/show/xxxxxx";
helplink.title = "Script_name V.x.x - help page";
document.getElementsByTagName('head').item(0).appendChild(helplink);
|
|
|
I haven't thought in any particular update system yet, as I was waiting for USO admins to answer (they don't seem to be available now: there is a spam backlog, no new blog entries, etc...). I have also read somewhere that a new Greasemonkey version is going to be ready soon, with new APIs and changes, so maybe they will solve this problem or help with it (I really can't imagine why this has been neglected, a @version and a @updateurl headers and we will be done) I will probably autocheck for updates if the last check was a week ago or more (the user will be able to disable autochecks with the settings dialog my script has). Your scheme seems ok (I'll probably look other script updaters for ideas, too), but it would be easier to code and more reliable if my suggestion gets implemented (script metadata served by USO in XML/JSON) |
|
|
a @version and a @updateurl headers and we will be done I don't see this happening in 0.8, or any time soon. |
|
|
To all those struggling with this issue: I just got a neat bit of code from Anthony Lieuallen that eliminates the need to duplicate script metadata in a JavaScript object. Now all I need is a way to detect updates on us.o (without artificially inflating my script's download stats) and I'll be all set to roll my own updater! The only way I can think to do this last part is to grab the "show" page from here and scan it for "Last Updated" - but not all scripts have a "Last Updated" date. I suppose I could add something like "@latest-version 2008/07/01" to my info text and have it scan for that, but that seems ugly, too. Anyone have any other ideas? |
|
|
Update: I just finished coding a self-updater. You can see it at work in this script, or get a copy of just the updater routine (along with copious documentation on how to incorporate it into your own scripts). I still think putting a coded release date on the info page is an ugly kludge, but I still haven't some up with a better idea, either. I do like the idea of us.o providing access to just a script's metadata in a bare format; has anyone suggested that on UserVoice yet? |
|
|
I do like the idea of us.o providing access to just a script's metadata in a bare format; has anyone suggested that on UserVoice yet?You can see an xml file with this information for every script by an author by viewing eg. http://userscripts.org/users/51934/scripts.xml If you want more info, I can't be bothered to find where I first saw this mentioned, but it was in a post by Henrik sometime over a year ago. |
|
|
That's interesting, but: a) I'd prefer something on a per-script rather than per-author basis;
|
|
|
I did a simple way of checking for updates, it works nice
|
|
|
Nice, yes, but it assumes that A) one is a regular visitor to userscripts.org; and
My self-updater makes neither of these presumptions. OTOH, I will grant that your script C) can be used by anyone, with zero programming experience; and
Different strokes for different folks, I guess. |
|
|
Yes, I saw your script or the other one when I was developing mine, then I was like damn it! It's done already... Then I was happy to know they were different. Indeed, my script could be named Presumptuous Updater, because he also assumes other little things that if don't happen it will silently fail. But I thought it wouldn't be a problem since no information is compromised thanks to GM_setValue... and it only would require you to try again to get it working. Nevertheless I use it a lot, and I never noticed one of those situations happening, nor anyone mention anything about it. |
|
|
US.o has added support for the @version header, but it would be nice if the webmaster can add an id or something to make it more accessible to userscripts |
|
|
I don't know if this is what you had in mind, but if you read this topic, you'll see that Jesse recently added URLs of the form |