Userscripts auto-updater @require library

« Previous 1 2 3 4 5 6 7 8 9 10 11 Next »

Jun 20, 2009 2:14am Photodeus Scriptwright	http://userscripts.uservoice.com/pages/795-gene... So I was reading the suggestion at uservoice and it got me thinking again. Wouldn't it be simple for uso to add a `// @require http//userscripts.org/some-updater-script.js?id=123456&checkinterval=2` into the script metadata block! This script would then be dynamically written to contain the correct url to ping every x days or so. The useful code snippet could be created by the uso community as an open source effort. Also, the inclusion process could be auto configured during the creation of the script. When a user uploads his script, they can opt-in to include a generic updater script http://userscripts.org/scripts/new [x] Add automatic update checking code check for updates every () 2 days ( ) 7 days ( ) 14 days Thoughts? Read this! EDIT: This thread has been very successful and a generic updater script has been created!* For more info, read http://userscripts.org/guides/16 Source code: http://code.google.com/p/usoupdater/

Jun 20, 2009 2:39am Tim Smart Scriptwright	Causes un-necessary strain on Userscripts.org for the @require. Probably just best to include updater code in your scripts. The best updater out there is most likely the one by sizzlemctwizzle: http://userscripts.org/scripts/show/38017

Jun 20, 2009 2:45am Photodeus Scriptwright	Why would there be any extra strain? It's just one .js file. The required library gets downloaded along with the user's script and installed on their system. There is no difference whatsoever if updates are checked in the script the user wrote (update checking inlined into script), or in the @required code (update code in a separate file).

Jun 20, 2009 3:36am JoeSimmons Scriptwright	Basically what http://userscripts.org/scripts/show/51513 does, but you have to wrap the metadata block (the scriptwright does anyway, but it's easy enough). @Tim: Not really. It gets downloaded only once each install, not on every run.

Jun 20, 2009 4:01am Photodeus Scriptwright	Your script is a bit long, but it's interesting. But just the type of thing we need! But it doesn't solve the problem of all scripts having automatic checking unless specifically programmed against your API. If integration could be 100% automated during the upload of a new script, this would be great....

Jun 20, 2009 4:13am JoeSimmons Scriptwright	Oh it's not my script :D It's Izzy's. Yes it would be very cool to have auto update requires and auto wrapped metadata blocks on first upload and all edits. It would be a lot of work though.

Jun 20, 2009 4:30am Marti Scriptwright	JoeSimmons wrote: auto wrapped metadata blocks on first upload and all edits. ...and probably quite illegal as discussed before in another topic somewhere... but changes are coming, just seem slower than usually anticipated.

Jun 20, 2009 4:34am Jesse Andrews Admin	one idea is to have a global recommended way to update scripts. Then let users know that they can use it?

Jun 20, 2009 4:42am Marti Scriptwright	Jesse Andrews wrote: one idea is to have a global recommended way to update scripts. Then let users know that they can use it? It actually appears to be the one major important thing missing from Greasefire... but your API here on USO still needs fine tuning for that to work... I'm doing what I can on my end in other circles... but progress is sometimes lagging but luckily I'm patient. :)

Jun 20, 2009 4:58am Photodeus Scriptwright	Ideally getting update capabilities into your script should be as simple as // @USO:auto-update-enabled ... USO_updateCheck();

Jun 20, 2009 6:27pm Photodeus Scriptwright	Oh, and to add on this idea: http://userscripts.uservoice.com/pages/795-gene... One method that I'm thinking of is that during each install we put a unique identifier into each script. We already have `// @uso:version 95981` Which only identifies the script revision/version. Maybe when the script gets installed, we can get a into our code. `// @uso:uuid 1234-ABCD-5678-FEDC` Along with an an injected var as first line in the code. `var USO_uuid = "1234-ABCD-5678-FEDC";` When USO_updateCheck() checks for new versions and the user agrees to upgrade the script, the updater library would fetch the new version passing the uuid along with the request. This way unique installs and upgrades can be easily separated. We could track Number of unique installs Which of these installed scripts have been updated and not Which installations are currently running in the wild (since the updater library will check for updates every x days, it can also send the uuid with it.) Now then there's the security concern. This could be a privacy infringement nightmare for users. They should be allowed to run and update scripts without risking their privacy. Also, in theory scriptwrights could to try to map an individual to the randomly generated uuid, and track their online activities etc. Advanced functions always lead to less privacy to the user. But this isn't much different from say an antivirus software package or Windows update "calling home" once in a while to find out if there are software updates. For a script writer it can be as much valuable to know how many unique installs there are currently installed and running on computers out there. Some userscripts are full-fledged applications that need to be updated and kept current, so it would be interesting to see how quickly new versions get adapted when an update is released. All of this can be done already, but it would be very nice to have a site like userscripts to provide a simple, generic API that offers these features (as a premium feature even).

Jun 21, 2009 5:59pm Buzzy Scriptwright	This is my custom autoUpdater :P. Checks for new version when the page is reloaded, not every 1, 2, 3 days... if (GM_getValue ("remember", true)){ autoUpdate (51336, "1.11"); }

Jun 21, 2009 7:24pm Tim Smart Scriptwright	Buzzy wrote: This is my custom autoUpdater :P. Checks for new version when the page is reloaded, not every 1, 2, 3 days... That is highly not recommended. Checking for updates every page reload x the number of scripts users = way too much un-necessary HTTP requests. Sorry for my comment on `@require` above, I didn't really know how it worked.

Jun 21, 2009 7:34pm JoeSimmons Scriptwright	Buzzy wrote: Checks for new version when the page is reloaded Very very bad method. That will make a lot of unneeded requests to uso.

Jun 21, 2009 7:47pm Buzzy Scriptwright	Uhhmmmm, thx for the advise. I'll implement that tomorrow. Bye. Ô_o!

Jun 21, 2009 8:02pm JoeSimmons Scriptwright	I like your design. "Actual version" should be "Current version" though.

Jun 21, 2009 8:23pm Jesse Andrews Admin	Every page load can be multiple times per page (if you trigger on iframes) In the past this has lead to people's scripts making thousands of requests per second to the site. And me having to block your script... Every 15 minutes seems like it would be good enough?

Jun 21, 2009 9:22pm Tim Smart Scriptwright	I made a @require library that auto updates your script using @uso:version in the meta.js. All you need to add to your script header is: // @require http://www.fostle.com/usoupdater.php?scriptid=12345&interval=24 If your script had the id of 12345 and you wanted to check every 24 hours, then the above would work for you. `interval` is optional, and defaults to a value of 48, which will check every 48 hours. The script library will run once on install, checking the meta for the current version ( @uso:version ) which it will then index using `GM_setValue()`, then it will check every now and again depending on the interval set. The PHP script produces a compressed version of the library, to view the source, append `source=1` to the end of the URL. For the sake of open-ness, the PHP file source is here: http://www.fostle.com/usoupdater.txt I have it hosted on my domain, but I don't mind the extra bandwidth. Maybe Jesse can host it?

Jun 21, 2009 9:34pm Jesse Andrews Admin	should it be called the "smart" updater resource ;) I'll host it (anyone see any issues with it?)

Jun 21, 2009 9:54pm Tim Smart Scriptwright	Jesse Andrews wrote: should it be called the "smart" updater resource ;) I'll host it (anyone see any issues with it?) Yeah I'm still adding a couple features. E.g. Abilty to force update with a Menu Command. I will also add in a check for GM_xmlhttpRequest to make sure the user is using Greasemonkey and most likely add a menu option to turn the updater off.

Jun 21, 2009 9:57pm Marti Scriptwright	Jesse Andrews wrote: anyone see any issues with it? Not knocking it... but this is sortof what I was saying the other night... Having a separate resource for this, like the meta.js routine, keeps it detached from the actual script. If it were "attached" to `http://userscripts.org/scripts/source/scriptid.user.js?id=12345&interval=24` would keep it better organized... but I haven't reverse engineered how you handle cookies and other items for normal installation of a script... that was the brain spark. Secondly I'm not fully understanding why it would be on a @require... GM only checks once on install for this to my knowledge... so how would any part of the script know to check again?... Does the php routine dynamically create a JavaScript updater function and deposit it in the folder where the core script resides? Lots of questions before implementing. It would be "wiser" imho, to have it on USO's namespace prefix... e.g. @uso:updater rather than a @require... not all user script engines on other platforms support @require and the suggestion of using it may be incongruent with it's current GM meaning... just some thoughts to ponder. Johan's also handling a thread on the dev group as well regarding building (or not) an update routine... so I'm thinking this might be something to review as well. What it basically boils down to is who wants to take responsibility for updating... I'm sure that any httpd can handle this, but depends on if USO wants the CPU load and bandwidth load for maintaining it. I'm all for minimizing the impact on a user script. The best updater I've seen is a function that someone posted on the dev group from twitter... granted it can still use some improvements, but it's small compact and simple... everyone elses here on USO, while it works and works well is "bulky" and has it's own "baggage"... As I've said time and again... there's always more than one way to skin a cat with coding... so perhaps a dynamically generated updater via PHP might be the route to go, but using @require key itself seems "fishy". Jesse Andrews wrote: Every 15 minutes seems like it would be good enough? EWWWW! ;) I would think a Calc/Geometry/Algebra function would be better for this... I've completely spaced the name of it... but I was thinking an interval between 1 hour and X days... checking the first time at 1 hour, then successive checks get longer in between if no updates are found.... until it reaches the maximum of X (say every 7 days)... this would definitely present a non-linear approach to updating, and would allow for those authors that are interactively fixing errors to have their users update as soon as possible... and when the author is "at rest" the script would check less often... when it encounters a new version, start the process all over at 1 hour and progressively get longer in between checks.

Jun 21, 2009 9:59pm Jesse Andrews Admin	for liability I don't think I want to modify people scripts. I can provide services that I can share that the authors can integrate - and having it clean is a goal :)

Jun 21, 2009 10:02pm Jesse Andrews Admin	The 15 minutes was a response to the guy who was updating every page load! I think 15 minutes is too often (firefox updates some things once a day, others once a week)

Jun 21, 2009 10:10pm Marti Scriptwright	Jesse Andrews wrote: for liability I don't think I want to modify people scripts. I'm assuming this was directed here... a user would still have the choice to include the @key... and it would generate a separate file for download on first install... thus eliminating the modification of the original user script... then just have the "API" for the updater up to the author on where to put it in their code... Photodeus, I think, mentioned it should be as simple as possible... like USO_update(); or maybe an object like uso.update() to allow better flexibility. Remember I'm still weighing the pro's vs cons still. Maybe it should be an @require then... going on this current tangent... just a lot to think about and what impacts are going to happen. If you are willing to host the PHP content, that is a definite plus... I haven't had time to fully comprehend Johan's comments on the dev group, but at first glance, it seems that he's leaning against incorporation into GM... but I still could be interpreting it incorrectly. P.S. I feel left out... WHERE'S MY PENGUIN!?!?!?! ;) Nice that the user agent and platform is shown now on each reply.

Jun 21, 2009 10:18pm Tim Smart Scriptwright	Marti, the PHP will dynamically generate a Javascript function, depending on the parameters you specify. It will grab the version on installation using a CURL operation, which I have yet to do. I haven't quite finished the Javascript code yet. If Jesse did host it, he could directly grab the script version without CURL.