Ocornu Webmonkey → 0.1a2

Comments and changes to this ticket

• 

  Olivier Cornu August 30th, 2009 @ 04:17 PM

  • Tag changed from “@high, feature” to “!high, #feature, :big”
  • Milestone set to “0.1a2”

• You flagged this item as spam.
  

  Erik Vold September 5th, 2009 @ 07:13 PM

  Hey Olivier,

  What is your plan for this feature?

  E

• 

  Olivier Cornu September 6th, 2009 @ 12:12 AM

  Well, one reason this is not available yet is that i don't have a "perfect plan". :-)

  Here is where i'm at:
  I intend to support uso's @version tag: if the URL you've installed your script from now hosts a script (same namespace/name) with a superior version number, mark this script for update.
  I'd like to support uso's *.meta.js URLs (for scripts with @version tags).
  I'd also like to make updates possible without @version tag: if the URL you've installed your script from now hosts a script with a different SHA1 than the one you've installed, mark this script for update.
  I'd like to identify scripts that have been user-edited since install time: should we still update? -- Diffs and merges are too much for now. ;-)

  Beside that, script updates should more or less work and behave as add-on updates.
  Script update checks should happen often enough, but not too often either (this is not a DDOS feature). Once per day, on browser start, seems fine. Manual request for update check would be good too.
  User should be asked to select/confirm which updatable script will be updated, as well as review source code if he wants to.
  Still, i'm worried that updates may be used to camouflage evil code. But then again, it's impossible to prevent that completely and automatically (i.e. without source code review).

  That's pretty much it. :-)
  What do you think?

• You flagged this item as spam.
  

  Erik Vold September 6th, 2009 @ 12:20 PM

  This does sound pretty good.

  I'd like to identify scripts that have been user-edited since install time: should we still update?

  Maybe ask the user to confirm they understand they are overwriting a script that was edited, or just alert them some how. If I edit a Firefox extension, I'm pretty sure that Firefox will still update that, without any warning or alert though.

  I'd like to see some metadata tags to reference the update urls, so that multiple sources would be available, and so that userscripts installed by manually dragging and dropping the script into the browser can update. The install url could be preferred, if this does not exists, then the uso url, if that DNE, then whatever else there is can be checked. The most common use would be to provide 1 or 2 urls I would think.

  Also I'm in favor of requiring the @version tag, because I think it would be needed to support the above.

• 

  Olivier Cornu September 6th, 2009 @ 02:32 PM

  Maybe ask the user to confirm they understand they are overwriting a script that was edited

  That sounds good to me. Only savvy users would edit a script anyway...

  I'd like to see some metadata tags to reference the update urls

  Contrary to what the @jsversion thread may lead one to think, i'm not for introducing new @tags every time a problem shows up. In fact, what i'm trying to do is to add support for existing ones (like @version). :-)
  This being said, i believe you are right: there should be an update URL tag for the reasons you've mentioned. Any idea about its name?
  However, i'm not sure it is a good thing to allow more than one. I feel that redundancy should be achieved by other means.

  I'm in favor of requiring the @version tag

  What's wrong with implicit (SHA1 based) version updates?

• You flagged this item as spam.
  

  Erik Vold September 6th, 2009 @ 03:51 PM

  What's wrong with implicit (SHA1 based) version updates?

  If there are two+ urls for updates, then with sha1 based version updates the urls would have to be updated at the same time, or else the userscript will constantly update.

  I can agree that starting with one update url is fine.

  i believe you are right: there should be an update URL tag for the reasons you've mentioned. Any idea about its name?

  Not yet, still thinking about that..

• You flagged this item as spam.
  

  Erik Vold September 7th, 2009 @ 08:07 AM

  I guess sha1 is fine if webmonkey remembers the previously used sha1(s), and compares the potential update script's sha1 to these. This logic could get a little complicated with multiple update urls though.

  For the update url I have a bunch of possibilities:
  1) @updateurl
  2) @updateuri
  3) @remoteurl
  4) @remoteuri
  5) @remote
  6) @remoteloc
  7) @scriptloc
  ...

  I favor @updateurl though because it matches the updateURL node in the FF Ext Install Manifest https://developer.mozilla.org/en/Install_Manifests#updateURL

• 

  Olivier Cornu September 7th, 2009 @ 11:13 AM

  Sounds good to me: i would vote for @updateurl (or @updateURL) for the same reason. We're down to a "case" decision. :-)

  I guess sha1 is fine if webmonkey remembers the previously used sha1(s), and compares the potential update script's sha1 to these.

  Yes, that's the plan. SHA1 wouldn't be used in the update process when there is an explicit @version. This being said, we may split the task in two: stick to @version updates on this ticket and open another one for implicit, SHA1 based updates.

  You really seem to be interested in multiple @updateURL and i still fail to see where the value is (mirroring?). Perhaps you could expand on that a bit?

• You flagged this item as spam.
  

  Erik Vold September 7th, 2009 @ 11:34 AM

  You really seem to be interested in multiple @updateURL and i still fail to see where the value is (mirroring?). Perhaps you could expand on that a bit?

  Ah forget it actually, one @updateurl is good enough. I just thought having alternative sources than uso could be good in case it is down, but it's not a big deal.

• 

  Olivier Cornu September 12th, 2009 @ 02:37 PM

  Ok, i'm choosing @updateURL (over @updateurl): this way it is exactly the same as Mozilla install manifest.
  Any objection?

• 

  Olivier Cornu September 12th, 2009 @ 10:44 PM

  • State changed from “new” to “open”

  Let's go. :-)

• 

  Olivier Cornu September 12th, 2009 @ 10:46 PM

  Implementation note: script version strings are compared using the standard nsIVersionComparator interface.

• You flagged this item as spam.
  

  Erik Vold September 13th, 2009 @ 07:36 AM

  Perhaps webmonkey could prefer @updateURL but accept a case-insensitive @updateurl, if @updateURL is not found? because if webmonkey uses @updateURL then @updateurl will never be used for anything else anyhow.

• 

  Olivier Cornu September 13th, 2009 @ 10:49 AM

  It could, but that would be a change of policy: header tag matching is case-sensitive in WM and GM.
  I suppose i'd rather pick one and stick to it, case sensitively speaking.

• You flagged this item as spam.
  

  Erik Vold September 14th, 2009 @ 07:25 AM

  Every current @key is also completely lowercase http://wiki.greasespot.net/Metadata_block

• 

  Olivier Cornu September 14th, 2009 @ 11:43 AM

  True, but on the other hand they're pretty much all single words (or so: are namespace or homepage 2 words?) and furthermore do not contain acronyms like URL... but frankly, that's a valid remark.
  Also, I just realized install.rdf's updateURL refers to the update.rdf file, not the actual add-on file URL -- that's updateLink.
  I'm not sure which one and which form are best...

• You flagged this item as spam.
  

  Erik Vold September 14th, 2009 @ 12:05 PM

  The actual ff ext file which is downloaded points to the location where the ff can find updates to the ff ext with updateURL node. Since the file where you can find updates for a userscript would also be the location of the update download, I'd stick with updateURL.

  I think all of the @keys should be case insensitive, and I would prefer to type them all lowercase as a userscript author. Maybe to get started use "updateURL' to exactly match FF exts, then a tentative update to make all @keys case insensitive would make me happy.

• 

  Olivier Cornu March 22nd, 2010 @ 12:21 PM

  You're right, let's go for @updateurl.

  I think all of the @keys should be case insensitive, and I would prefer to type them all lowercase as a userscript author

  Current implementation is case-sensitive, but all tags are lower-case, so i see no technical issue in switching to case-insensitive. Although i agree we can arbitrarily do it with WM, it won't change other userscript engines so scripts will likely remain lower-case. There's long been a need for standards talks between userscript engines…
  In fact the whole "// @tag" pattern check is exceedingly strict in GM. It could use some syntactic sugar and be more flexible with white-spaces as well as letter case.

  Back to the core update feature, a good deal of the problem is dealing with includes/excludes that the user may have altered.
  Basically, one needs to distinguish between script-set includes/excludes and user-set includes/excludes. When a script is updated only script-set rules get updated, user-set rules remain identical and still apply.
  GM used to mix them all up, it seems it now wants to remove such user settings (users should edit the script file instead).