search

greasyfork-org / greasyfork

An online repository of user scripts.
https://greasyfork.org
GNU General Public License v3.0
1.49k stars 445 forks source link

Update update updates #46

Closed JasonBarnabe closed 10 years ago

JasonBarnabe commented 10 years ago

Per everything I've learned at https://github.com/greasemonkey/greasemonkey/issues/1886

jerone commented 10 years ago

All my scripts are on Github, which is my main distribution center. I use GreaseFork (GF) and Userscripts.org (USO) only as secondary distribution centers. In my scripts, posted on GF, I have defined the @downloadURL to the scripts on Github. After reading the discussion above I noted that you both override the @downloadURL and @updateURL linking it to the GF site. That means any updates on Github won't be found.

Is it possible that you only set the @downloadURL and @updateURL when not defined?

If you don't set anything, the update URL is the download URL is the URL you actually got the script from...

And according above statement from @arantius defining the @downloadURL and @updateURL isn't really needed, only if you define some sort of meta.js, which you do, so I have to change all my scripts to incluse also the @updateURL to check for updates from Github and download it from Github too.

Edit: updated quote.

LouCypher commented 10 years ago

I see GF also change @namespace metadata.

This is bad because if users have installed from different host a script before and then install the same script again from GF, they will have two same scripts.

That's because Greasemonkey and Scriptish use @namespace as part of add-on id in the following format:

Test case

LouCypher commented 10 years ago

Note that Scriptish uses @namespace as add-on id only if the script doesn't have @id metadata.

jerone commented 10 years ago

I see GF also change @namespace metadata.

Confirm. That's even worse. Didn't noticed that before.

Am getting not so happy with all those changes to my userscripts. All those cases where there are no @name, @namespaces, @downloadURL and @updateURL are handled by GM self (don't know about Scriptish & TM).

arantius commented 10 years ago

I use GreaseFork (GF) and Userscripts.org (USO) only as secondary distribution centers. In my scripts, posted on GF, I have defined the @downloadURL to the scripts on Github.

That's probably the one case where setting these two properties does make sense.

Some comments above make it clear that my comments are being misinterpreted, likely bits being taken out of context. Please reread the whole thing. Specifically, the quote in the first comment omits the critical conditional that the sentence started with: "If you don't set anything ...".

And also, as said above by others, a script host should absolutely not go messing with the contents of the script at all, metadata or not. Changing the @namespace will indeed break things.

jerone commented 10 years ago

Some comments above make it clear that my comments are being misinterpreted, likely bits being taken out of context. Please reread the whole thing. Specifically, the quote in the first comment omits the critical conditional that the sentence started with: "If you don't set anything ...".

Don't know what you mean, but I updated the quote.

JasonBarnabe commented 10 years ago

The intention was to make it easier for script writers by not having these bits required, but I didn't adequately understand their importance when actually set.

The new behaviour will be that @namespace and @version will not be rewritten if the author provides them. The site will provide them if they are missing and the author opts in. It will also do validation to ensure that @namespace doesn't change and @version goes up, but the author can override if necessary.

The @-URLs will still be stripped. For the case where your main hosting spot is GitHub (or anywhere else), I'm going to be offering automatic syncing, so if you update it there, the code will be pulled in here. See #17.

Greasy Fork saves the code as the author provided it, so when I put the changes, I can regenerate it.

cletusc commented 10 years ago

The @-URLs will still be stripped.

If they are provided by the author, they should not be stripped. The only time I am OK with those being stripped is in the case of an old version so that it doesn't update.

JasonBarnabe commented 10 years ago

My issue with off-site @-URLs is essentially the same as with @require: that it makes things non-transparent for the user. A nice script could be posted with an off-site @-URL that one days gets swapped out for some malware. Of course, someone could do that anyway with code directly on Greasy Fork, but it would be more noticeable (with version history and potentially through automatic checks) and it would be reversible (by swapping the malicious code for something benign and letting the auto-update happen).

I know some people disagree with my restricting what authors can post, but I think it's necessary to maintain user safety. I think the syncing feature will accomplish what authors want to do (posting their script once in their location of choice and having Greasy Fork serve out the updated script) while keeping users safe.

arantius commented 10 years ago

As long as you're really transparent, those sorts of changes make sense to me. I applaud improvements in the community around hosting/sharing/validating user scripts. I'm not surprised if the first few steps are a bit wobbly.

jerone commented 10 years ago

The new behaviour will be that @namespace and @version will not be rewritten if the author provides them. The site will provide them if they are missing and the author opts in. It will also do validation to ensure that @namespace doesn't change and @version goes up, but the author can override if necessary.

This is an improvement for novice scriptwriters. 'Experienced' scriptwriters will use them anyways. Good choice.

The @-URLs will still be stripped.

I understand your opinion about user safety and stuff. But I want to make my situation, as a scriptwriter, also clear to you. So I'm a scriptwriter and I have multiple scripts. When I make a new one or update an existing one, it will be committed on my source control system (VCS) (Github since recently). To 'advertise' those scripts I had to upload them to USO, now also GF and soon to OUJS. Ok, that's fine, because I set my @updateURL to Github I only have to upload them once and GM updater will do the rest. Now I'm learning about overriding the @updateURL, which forces me to update every uploaded script every time I make a new version on my VCS. To me this sound a bit redundant.

For the case where your main hosting spot is GitHub (or anywhere else), I'm going to be offering automatic syncing, so if you update it there, the code will be pulled in here. See #17.

This feature is already implemented in OUJS. If you implement this feature too, then it will save me some time.

Don't get me wrong, user safety is very important, but I preferred to see some sort of reviewing system, like FF extension does. I would commit some of my time to review other scripts.

Anyways, those were my two cents. Keep up the great work.

arantius commented 10 years ago

Don't get me wrong, user safety is very important, but I preferred to see some sort of reviewing system, like FF extension does. I would decade my time to review other scripts.

But if the update happens outside of the system (i.e. if you allow the updateURL to point elsewhere), how is it reviewed? At AMO, the update URL is indeed forced to point back to AMO (removed, so that the default does?).

https://developer.mozilla.org/en-US/Add-ons/Install_Manifests#updateURL

For add-ons hosted on addons.mozilla.org: You may not specify an updateURL property.

JasonBarnabe commented 10 years ago

This feature is already implemented in OUJS. If you implement this feature too, then it will save me some time.

This won't just save you some time, it should be equivalent in the "time required" department to what you were planning with @updateURL. I think you may have missed (or I may have not explained properly) the auto part of auto-sync of #17. Greasy Fork will periodically check your GitHub repo for changes. So what you would have to do is go to Greasy Fork once, say "this is my script's URL", and then you never have to do anything else on Greasy Fork. It will pull in the updates by itself.

Don't get me wrong, user safety is very important, but I preferred to see some sort of reviewing system, like FF extension does. I would decade my time to review other scripts.

But if the update happens outside of the system (i.e. if you allow the updateURL to point elsewhere), how is it reviewed? At AMO, the update URL is indeed forced to point back to AMO (removed, so that the default does?).

It's pretty useful to compare what I'm trying to do here with what AMO does.

I think if I made it as restrictive as AMO, people would go nuts!

JasonBarnabe commented 10 years ago

OK, changes committed:

All submitted scripts have been regenerated. Let's see how it goes!

cletusc commented 10 years ago

Excellent. I do understand the reasoning and am OK with it (the stripping of @-URL meta) on that basis. Looks good to me. :+1:

LouCypher commented 10 years ago

@downloadURL, and @updateURL are stripped

Actually they shouldn't be.

If you right click on .user.js link and select View User Script Source with Greasemonkey, GM download it to temp folder, and if you click the Install button on notification, GM install it from temp folder and use file://*.user.js as downloadURL and updateURL script properties and will have updateIsSecure=false property.

If the script source on web host is updated, the script you installed won't be updated automatically.

LouCypher commented 10 years ago

my comment above

Maybe it's more Greasemonkey issue. @arantius?

arantius commented 10 years ago

The install-time double-serving avoidance has nothing to do with updates.