Updater in Greasemonkey core

in Userscripts.org discussion
Subscribe to Updater in Greasemonkey core 38 posts, 6 voices



lazyttrick Scriptwright
FirefoxWindows

I was just pointing this out so that hopefully the future GM updater doesn't do that.

Let me be honest for once: I'm sorry my shitty updater wasn't good enough for you.

edit: #$@#$!%!#%@#%

 
sizzlemctwizzle Scriptwright
FirefoxMacintosh

Firstly, I'm disappointed that you took my statements so personally. I'm in this discussion to talk about the proposed implementation of a updater in GM, not to bash you or your updater.

lazyttrick wrote:
I'm sorry my shitty updater wasn't good enough for you.
I never said your updater was shitty. In fact, on the contrary I think its amazing, hence why I've given it 5 stars. Just because I don't currently use it because I've had problems with it doesn't mean I don't realize the great work you have done.
lazyttrick wrote:
I'm glad you could indirectly call me "just stupid imo" right after I pointed out a possible problem with your original idea.
You took my statement the wrong way. When I said that we were talking about methods of update checking. You were advocating checking for all updates at once like you do in your updater. I was saying only scripts that are used(which would not include disabled scripts) should be checked for updates. I admit that now that I read what I said again it sounds like I was calling your updater stupid for checking for updates of disabled scripts, but what I really meant is that if the future GM updater checked for updates of disabled scripts that would be stupid. I'm sorry for my poor choice of wording that lead to this misunderstanding.

 
lazyttrick Scriptwright
FirefoxWindows

communication can be tricky sometimes, I'm sorry I misunderstood that part too...

I think these ideas are good for a start, though they are spread all over the topic...

 
sizzlemctwizzle Scriptwright
FirefoxMacintosh

Rycochet wrote:
A @source meta for scripts to say where they come from - this would point at the uso install link for uso scripts, or whatever the source install link is for other scripts.
Since when you install a user script Greasemonkey will know where it comes from we can just store that then. I also don't like the idea of adding a bunch of extra meta keys, but @homepage(equivalent to your @website) might not be that bad of an idea. A link in the manage scripts dialog to go to that page to get more info about a script might me useful.
Rycochet wrote:
GM to store a hash of the installed version on install - and only automate the install if the hash hasn't changed (if it changes then no need to check every time). Any scripts that don't match the hash get shown to the user with a double-check tickbox and BIG WARNING that it's different etc.
That'd take care of the problem of overwriting scripts, but I don't know how memory intensive it is to generate hashes from a user script's source in Javascript so it might not be worth it.
Rycochet wrote:
integrated with the Addons panel etc
changing the GM UI is a completely different issue, but I agree it would really be nice to have better GM integration in Firefox.
lazyttrick wrote:
though they are spread all over the topic...
Yeah that can be a problem. Anyone who wants to get all the ideas will have to read the entire topic and as the topic grows the more difficult of a task that will become. This topic has already been linked to in the related GM issue so hopefully these ideas will become of some use. I don't really have the extension development experience to initiate anything myself, so I've just got to wait for someone else get the ball rolling before I can hope to contribute any actual code.

 
Marti Scriptwright
FirefoxX11

lazyttrick wrote:
Let me be honest for once: I'm sorry my shitty updater wasn't good enough for you.
Your updater is just fine just a different approach. Everyone here should realize that it is still up to the end user on what they choose. I would hope that I've made this very clear throughout all of the discussions over the last year. I try my best to help everyone when I can with another viewpoint. Constructive criticism is a good thing until someones ego gets in the way and feelings get hurt. I do my best to choose words carefully but sometimes that's not enough to convey what is meant. The spirit of collaboration is to figure out what needs improvement... not to argue "my way or the highway".

lazyttrick wrote:
I think these ideas are good for a start, though they are spread all over the topic
I'm already to the point where I'm going to need to reread it again and again.

sizzlemctwizzle wrote:
so hopefully these ideas will become of some use.
They are and eventually it will come to fruition but patience is a virtue.


We all have our own pace and being impatient can be a double-edged sword. I still prefer the incremental approach as a lot of things coming down the pipeline are newer to some of us and some aren't. Tim's initial post is out of his impatience with upstream... They will get around to it but there's still a lot of voices to be heard in the meantime.

 
sizzlemctwizzle Scriptwright
FirefoxMacintosh

Marti wrote:
Tim's initial post is out of his impatience with upstream...
His impatience is valid though. Update checking has been an issue since the very beginning of Greasemonkey, but it is not something that is trivial and can't be done over night. He's right that it is a feature that is simple to implement, but defining how it should be implemented is the difficult part. I think he, like myself and others I assume, would just like a little head-way to be made and discussing the details of this feature is the first step towards that end. Plus there is no harm in suggesting and debating ideas, while we wait for GM devs to get around to it(the issue has already been labeled so that is a good sign).

 
Marti Scriptwright
FirefoxX11

sizzlemctwizzle wrote:
it is not something that is trivial and can be done over night.
Did you mean can't?... all the updaters around are there to "fill the void"... It's one of the reasons I'm dedicating more time here than Moz right now.

 
sizzlemctwizzle Scriptwright
FirefoxMacintosh

Marti wrote:
Did you mean can't?
Yes, but I thought my "not" earlier in the sentence took care of that negation for me, but perhaps I'm wrong. I've never been very good with grammar, as you've already been made aware lol.

 
Marti Scriptwright
FirefoxX11

sizzlemctwizzle wrote:
Yes
Okay... I agree the fundamentals of shifting the management dialog to the Mozilla Preferences dialog is a large task but it also has several small steps to come first. I just have to remind myself that there are a lot of good ideas for updating out there. I'm still trying to figure out if updating can ever work cross-browser... but that's not the focus of this topic. The "Defacto Standard" that Aaron has made is a bit incomplete and he's "outies" so that leaves it up to upstream to figure out a way... this includes anyone who has forked GM... this is one of the primary reasons I interact here. The clearer something is made besides "It should just do it" the better.

 
Rycochet Scriptwright
FirefoxWindows

I know that the install location is stored in the script (mentioned earlier in the thread too) - however that doesn't really help if the script wasn't installed from the "official" location, ie. the place where the coder puts updates...

As an example - person a patches a script and sends it to person b. They like it but won't know about updates to the original script without checking for updates (manually or otherwise)...

Now the update scripts, and the various update snippets, all check a known location for the new version - if people using them want to swap to the GM update code then they need to be able to specify that location. If it was easy to check the config.xml for the source location then no doubt the update checkers that are just @required would make use of that and not just link to the uso scripts (sorry if they do, I've only had a quick look).

An old link about javascript md5 if here - http://www.myersdaily.org/joseph/javascript/md5... - which shows it's not exactly too slow to use...

The homepage/website link isn't just an "update only" idea... Sort of like having an "about" page, but not needing to code it into the source directly ;-)

 
sizzlemctwizzle Scriptwright
ChromeLinux

Just stumbled on this topic. Now that Greasemonkey has had an updater for awhile now, what does everyone think? Is it what you hoped for?

 
JoeSimmons Scriptwright
FirefoxWindows

sizzlemctwizzle wrote:
Just stumbled on this topic. Now that Greasemonkey has had an updater for awhile now, what does everyone think? Is it what you hoped for?

I haven't used it much, but it seems to work well.

 
Marti Scriptwright
FirefoxX11

sizzlemctwizzle wrote:
... Is it what you hoped for?
No. The spyware domain that Greasemonkey (GM) currently uses for meta.js when not specified correctly is inappropriate and is definitely able to track a scripts daily usage without the consent of the end user. (e.g. opt in or opt out). Other than that issue it could be viable as a silent update method.

What is going to make things worse for Userscripts.org (USO) and its Users is when a ScriptWright uses their warped script homepage for the @updateURL in the upstream nightly. If the Man In The Middle (MITM) constant eavesdropping/existence fails to return the meta.js from whatever location this will then use the scripts native @updateURL. This has the potential to cause yet another DDoS on USO by incorrectly crossing the recently established separation of source code (user.js), meta.js routine and page content; perhaps return a malformed user.js; and/or at the very least an exception.

The attempt to match anything from ~\/scripts\/\w+\/\d+\.user\.js is one of the lesser intelligent ideas that has been introduced from upstream GM via updating since your initially safe, working, independent classic updating mechanism that was adopted in 0.9.12.

See the latest upstream nightly, continually errored, commit at upstream@516da86 and one correction at upstream@524a7c7.

As usual I will be near parallel forking GM with a release candidate in my crossstream repo files that removes the malware CDN. AMO has not approved 1.11.0 yet and the above commits will probably be released in 1.12.0ish. One can still use uso - installWith to optionally dis/allow the use of the Greasemonkey Updater (GMU) via the Add-On Updater (AOU)... however with the latest upstream commits always testing presence, it will always throw your IP to the domain regardless during update checks.


Further recent commentary: