As promised earlier, here is my (yes, at this point, my personal ideas offered up for discussion, only) plan for what I'd like to see in GM 0.9. With the new "major" version number bump comes a whole bunch of user-visible features.
The reality is that it will be a while, as we add smaller features/fixes to 0.8, before we get to this. But having a clear plan in place will make it go smoother when we get to it. So definitely don't go writing any code yet. It's fine if you do, but less likely to be accepted until something is agreed upon.
== UI == Remove the existing Manage Scripts dialog. Move its functionality into a tab of the Add-Ons dialog. (As often mentioned, this is like Stylish. It's gotten positive feedback when mentioned recently, and it's also something I've personally felt was a good idea for a long time. From 2006 and 2007 (!): [1] [2])
The Greasemonkey extension's "Options" dialog, now that it is not "Manage Scripts", will edit global type settings: * The script editor * Global excludes (future?)
The UI to enable/disable/uninstall scripts would now work (and look) just like first-class extensions: buttons in the selected item. Description will work and look like first-class extensions: it will be truncated, unless that item is selected, then the whole thing will display. The selected item will have an "Edit" button where extensions have "Options".
I personally wouldn't prioritize it, but based on feedback from recent mentions of this idea, perhaps we would add a search/filter box at the top. I'd imagine it looks just like the search box at the top of the "get add-ons" tab. Maybe even with a similar "browse all" link, to us.o.
There will be no UI to edit @include/@exclude rules. This will be done by editing the script itself. (See next section.)
== Metadata == All metadata will be read _from the script_ as the authoritative source (no more config.xml). It should probably be cached in memory, for performance, but whenever accessed, checked against the mtime of the relevant file, and reloaded if necessary.
Changing the @name (or @namespace) of the script will thus potentially cause major problems. We will throw away @namespace, and add a (required!) @id imperative (again, just like extensions). The @id imperative must contain any globally-unique string. If it is not present at install time, it will be generated by hashing the contents of the script, and injected. This will mean a one-time migration of stored script preferences (and @id imperatives).
On Fri, Nov 6, 2009 at 07:22, Anthony Lieuallen <arant...@gmail.com> wrote: > As promised earlier, here is my (yes, at this point, my personal ideas > offered up for discussion, only) plan for what I'd like to see in GM > 0.9.
I'm behind all of them too. Another one I think we also might want to sneak into 0.9 is a @nosandbox directive, perhaps more aptly named @nogmapi, or some such, injecting the script at DOMContentLoaded via the location.href = "javascript:<script contents here>" hack, without any bells and whistles at all of Greasemonkey's (except the anonymous function enclosure, unless there's a @unwrap directive -- which retains its function, for maximum congruence and utility for power scriptwrights that know what they are doing).
It's an easy feature that will help get us back to how javascript programming should work and feel, get us back to where the native capabilities of the browser are available and work the way they always do. With HTML 5 and other coming browser tech, the crutch that is the Greasemonkey API will become less and less crucial for larger and larger swaths of scripts -- we might even find reason to eventually make this kind of injection the default in 1.0.
Olivier Cornu does have a point that the XPCNativeWrapper environment's guarantees of actually invoking the DOM API methods when we try, and not some light and magic show set up by the web page we inject into via __defineGetter__, __defineSetter__ and the like is valid, but hardly merits that straitjacket to be forced on scriptwrights that do not request it.
> .. a @nosandbox directive, perhaps more aptly named @nogmapi, or some > such, injecting the script at DOMContentLoaded via the location.href > = "javascript:<script contents here>" hack.. With HTML 5 and other > coming browser tech, the crutch that is the Greasemonkey API will > become less and less crucial for larger and larger swaths of scripts > -- we might even find reason to eventually make this kind of > injection the default in 1.0.
I'm actually in the middle of a rather lengthy post of for-1.0 ideas, that are all hinging around almost exactly this sort of stuff.
But either way, I think big changes to the execution model should wait a bit longer than all the UI-centric stuff.
> == Metadata == > All metadata will be read _from the script_ as the authoritative source > (no more config.xml).
I was really exited about this idea back in November when I wrote that.
Today however, I've actually tried to implement it and discovered that it doesn't work. The specification for @require and @resource make it difficult and/or impossible to work exclusively with the metadata. And almost completely impossible to handle legacy installs properly.
The files that @require lines are stored in are _usually_ identical to the filename in the URL. But if two files of the same name (at different hosts/paths) are referenced, it's no longer possible to know for sure which file relates to which @require line. This gets extremely hairy if they are edited later.
I currently don't have a complete solution to this problem. It may end up that the @include/@exclude lines are read live from the file, but other "important" lines (@name, @require, etc) are only read at install time, into config.xml as always.
When I was thinking about this I was pushing in the other direction, since the less file access the better, that the script should be duplicated and all metadata and comments and whitespace removed, and that version is executed at runtime. In Google chrome simply updating the script doesn't count, you have to reload extension to get it to recognize changes, I imagine this is for speed purposes. I understand why people would want @include/exclude to be update-able from script because all novice script authors update the @include and expect it to show up on another site immediately, which can be frustrating/discouraging, but I don't think the metadata block should be considered at all unless the file was modified, and checking file modified times all the time doesn't seem all that great as a solution but I don't think parsing this every time you visit the page makes sense either. All delays should be avoided. I would imagine some separate process that scans for changes periodically makes more sense than doing it when there haven't been any changes. A simple way to trigger rescan of the metadata for any given script, via javascript even, would probably be the most superior method. If its hidden in script management dialog then it doesn't make as much sense, but a simple button to re-load metadata would be a nice feature for rapid development, and ideally simply visiting some sort of URL would trigger the metadata reload for a particular script. I'm wondering to myself how often config.xml is read and if it would make sense to read only a chunk of the file rather than parsing the whole thing.
On Tue, Mar 16, 2010 at 12:59 PM, Anthony Lieuallen <arant...@gmail.com>wrote:
>> == Metadata == >> All metadata will be read _from the script_ as the authoritative source >> (no more config.xml).
> I was really exited about this idea back in November when I wrote that.
> Today however, I've actually tried to implement it and discovered that it > doesn't work. The specification for @require and @resource make it > difficult and/or impossible to work exclusively with the metadata. And > almost completely impossible to handle legacy installs properly.
> The files that @require lines are stored in are _usually_ identical to the > filename in the URL. But if two files of the same name (at different > hosts/paths) are referenced, it's no longer possible to know for sure which > file relates to which @require line. This gets extremely hairy if they are > edited later.
> I currently don't have a complete solution to this problem. It may end up > that the @include/@exclude lines are read live from the file, but other > "important" lines (@name, @require, etc) are only read at install time, into > config.xml as always.
> -- > You received this message because you are subscribed to the Google Groups > "greasemonkey-dev" group. > To post to this group, send email to greasemonkey-dev@googlegroups.com. > To unsubscribe from this group, send email to > greasemonkey-dev+unsubscribe@googlegroups.com<greasemonkey-dev%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/greasemonkey-dev?hl=en.
> When I was thinking about this I was pushing in the other direction, since > the less file access the better...
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"
I suspect you mis-estimate the cost of the occasional file-modified-time check. I have no worries whatsoever of the perceived performance of a read-from-the-file metadata approach.
I, also, find the edit-save-reload development model for Greasemonkey today to not only be useful, but critical. I want to do almost anything to make development faster and easier. Simplifying changing the script is important.
This perhaps isn't an ideal solution but perhaps having seperate user/dev modes could be viable?
In short, GM is in 'user mode' by default which respects updates / changes to @tags except for the problematic ones ( @resource / @require / @name (?) for example ). Alterations to these tags could trigger a prompt asking whether to respect the change - not a problematic issue for occasional changes. 'Dev mode' would essenially be the same but switch off those prompts and just force GM to respect all changes to @ tags on every run of the script.
Actually, now that I think about it, actual user/dev modes on a global level vs having an option to just disable the prompt may be overkill but if other features fall neatly into these categories then I don't see why this can't happen. =]
> The files that @require lines are stored in are _usually_ identical to the > filename in the URL. But if two files of the same name (at different > hosts/paths) are referenced, it's no longer possible to know for sure which > file relates to which @require line. This gets extremely hairy if they are > edited later.
As for the multiple @requires, rather than store them in the directory root, perhaps the files could be stored in a directory structure that reflects the @require itself?
If it is preferred to keep the extra files in a single directory (and avoid the many dirs within sub-dirs), I suppose that an alternative to this would be to have the script rename the @require/@resource files where conflicts occur and have something similar to a config.xml in each script dir that keeps track of which file is which? This is erring toward a manifest-type file however which I vaguely remember being disliked in previous discussions, though it would only be produced in what I assume are very rare conditions where filenames conflict?
Regards, kwah
On 16 March 2010 16:59, Anthony Lieuallen <arant...@gmail.com> wrote:
>> == Metadata == >> All metadata will be read _from the script_ as the authoritative source >> (no more config.xml).
> I was really exited about this idea back in November when I wrote that.
> Today however, I've actually tried to implement it and discovered that it > doesn't work. The specification for @require and @resource make it > difficult and/or impossible to work exclusively with the metadata. And > almost completely impossible to handle legacy installs properly.
> The files that @require lines are stored in are _usually_ identical to the > filename in the URL. But if two files of the same name (at different > hosts/paths) are referenced, it's no longer possible to know for sure which > file relates to which @require line. This gets extremely hairy if they are > edited later.
> I currently don't have a complete solution to this problem. It may end up > that the @include/@exclude lines are read live from the file, but other > "important" lines (@name, @require, etc) are only read at install time, into > config.xml as always.
> -- > You received this message because you are subscribed to the Google Groups > "greasemonkey-dev" group. > To post to this group, send email to greasemonkey-dev@googlegroups.com. > To unsubscribe from this group, send email to > greasemonkey-dev+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/greasemonkey-dev?hl=en.
> .. As for the multiple @requires, rather than store them in the > directory root, perhaps ..
And existing installs? Migration is difficult at best.
> .. have the script rename the @require/@resource files where > conflicts occur and have something similar to a config.xml in each > script dir ..
And then when the file is edited, what? The script author has to know to open up this other file and edit it too? And how do we reconcile existing installs?
On 17 March 2010 12:59, Anthony Lieuallen <arant...@gmail.com> wrote:
> On 03/16/10 18:11, Kwah wrote:
>> .. As for the multiple @requires, rather than store them in the >> directory root, perhaps ..
> And existing installs? Migration is difficult at best.
Check if config.xml currently exists. If so,continue to obey it ('as normal') until it is no longer needed (due to reinstallations / uninstallations). For all new script installs, do not update/use the config.xml file and use the 'new'/alternative config.xml-free solution.
I admit that it is a messy solution during the transition (which I suppose could never end in some circumstances) but will eventually wean the people that this will affect most, away from config.xml quite quickly. By 'the people that this will affect', I mean those that regularly install / edit scripts.
To affect everybody, would it not be possible to just restructure the filesystem automagically after the updated GM install based on whether config.xml is present (with permission from the user, of course)? If a manual trigger (or both, for those who initially say no) is preferred, add a button somewhere (with appropriate warnings) to trigger the restructuring? Perhaps a 'refresh metadata'-type message.
By 'restructuring', I mean having the script do what would effectively 'reinstall' the script according to the 'new' structure (minus config.xml data) *but* if the @require/@resource'd files are already present on the filesystem, just move them (instead of downloading them) in order to preserve any modifications already made.
If new files need to be downloaded, a prompt stating that gm cannot obey the 'new' metadata cannot be obeyed due to the files not being present on the current install, would you like to download them? (I'm not sure how to work in the warnining that this may change/break how the current script functions though).
>> .. have the script rename the @require/@resource files where >> conflicts occur and have something similar to a config.xml in each >> script dir ..
> And then when the file is edited, what? The script author has to know to > open up this other file and edit it too?
I was imagining this extra file would be present *only* when conflicts occur and is used internally to "remember" which file is which. This wouldn't protect against file renames of the conflicting @require/@resource's, but doing that on the current version without editing config.xml breaks things too.
Do you have any data about how many people this might affect? From current experience I would suggest that conflicting @require/@resources are rare but I may have just been lucky to have never been affected by it.
I'm thinking that abandoning some central config is a bad idea. What's going to happen is you'll have to read every single script on every single page you visit just to check if you need to include it or not? That doesn't seem like an ideal solution unless this data is cached somehow, and thats what it seems like config.xml is for in the first place... although when you get a lot of scripts its too big to be fast. I like the idea of organizing scripts based on the file-system because then if the directory youtube.comdoesn't exist there are no scripts to include for that site, but still if you change an include in a script does it then need to be copied to a new directory? I really think centralized meta-data makes sense, the only problem is knowing when to update it or if it hasn't changed and keeping it as small as possible. If resources are only downloaded at installation time then doesn't metadata about each resource need to be cached somewhere before you'll know if they changed the path or updated, in which case you need to download it again. Perhaps resources are in a separate directory structure entirely from scripts and only downloaded if they don't exist or prompted that a different version exists at update time.
I think it is a big headache migrating if it's already reasonable ok how it is now. I think that the metadata block should just be hashed or something and if a change is present you will detect it pretty easily... of course if you need to know which thing changed then you need to cache the entire block, which is mostly what config.xml is doing, but splitting that file up makes sense, to leave the scripts and resources where they are and make a config.xml for youtube.com that can be easily voided or tested for and only pertains to scripts that run on that site. Then the oversized config.xml is no longer an issue.
On Wed, Mar 17, 2010 at 10:15 AM, Kwah <kwa...@gmail.com> wrote: > On 17 March 2010 12:59, Anthony Lieuallen <arant...@gmail.com> wrote: > > On 03/16/10 18:11, Kwah wrote:
> >> .. As for the multiple @requires, rather than store them in the > >> directory root, perhaps ..
> > And existing installs? Migration is difficult at best.
> Check if config.xml currently exists. If so,continue to obey it ('as > normal') until it is no longer needed (due to reinstallations / > uninstallations). > For all new script installs, do not update/use the config.xml file and > use the 'new'/alternative config.xml-free solution.
> I admit that it is a messy solution during the transition (which I > suppose could never end in some circumstances) but will eventually > wean the people that this will affect most, away from config.xml quite > quickly. By 'the people that this will affect', I mean those that > regularly install / edit scripts.
> To affect everybody, would it not be possible to just restructure the > filesystem automagically after the updated GM install based on whether > config.xml is present (with permission from the user, of course)? > If a manual trigger (or both, for those who initially say no) is > preferred, add a button somewhere (with appropriate warnings) to > trigger the restructuring? Perhaps a 'refresh metadata'-type message.
> By 'restructuring', I mean having the script do what would effectively > 'reinstall' the script according to the 'new' structure (minus > config.xml data) *but* if the @require/@resource'd files are already > present on the filesystem, just move them (instead of downloading > them) in order to preserve any modifications already made.
> If new files need to be downloaded, a prompt stating that gm cannot > obey the 'new' metadata cannot be obeyed due to the files not being > present on the current install, would you like to download them? (I'm > not sure how to work in the warnining that this may change/break how > the current script functions though).
> >> .. have the script rename the @require/@resource files where > >> conflicts occur and have something similar to a config.xml in each > >> script dir ..
> > And then when the file is edited, what? The script author has to know to > > open up this other file and edit it too?
> I was imagining this extra file would be present *only* when conflicts > occur and is used internally to "remember" which file is which. This > wouldn't protect against file renames of the conflicting > @require/@resource's, but doing that on the current version without > editing config.xml breaks things too.
> Do you have any data about how many people this might affect? From > current experience I would suggest that conflicting > @require/@resources are rare but I may have just been lucky to have > never been affected by it.
> > And how do we reconcile existing > > installs?
> "Import" it from the existing config.xml?
> -- > You received this message because you are subscribed to the Google Groups > "greasemonkey-dev" group. > To post to this group, send email to greasemonkey-dev@googlegroups.com. > To unsubscribe from this group, send email to > greasemonkey-dev+unsubscribe@googlegroups.com<greasemonkey-dev%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/greasemonkey-dev?hl=en.
Just cache the config centrally in memory and check last access times, as mentioned. (The access-time check can be parallelized, so as not to delay load.)
> I'm thinking that abandoning some central config is a bad idea. > What's going to happen is you'll have to read every single script on > every single page you visit just to check if you need to include it or > not? That doesn't seem like an ideal solution unless this data is > cached somehow, and thats what it seems like config.xml is for in the > first place... although when you get a lot of scripts its too big to > be fast. I like the idea of organizing scripts based on > the file-system because then if the directory youtube.com > <http://youtube.com> doesn't exist there are no scripts to include for > that site, but still if you change an include in a script does it then > need to be copied to a new directory? I really think centralized > meta-data makes sense, the only problem is knowing when to update it > or if it hasn't changed and keeping it as small as possible. If > resources are only downloaded at installation time then doesn't > metadata about each resource need to be cached somewhere before you'll > know if they changed the path or updated, in which case you need to > download it again. Perhaps resources are in a separate directory > structure entirely from scripts and only downloaded if they don't > exist or prompted that a different version exists at update time.
> I think it is a big headache migrating if it's already reasonable ok > how it is now. I think that the metadata block should just be hashed > or something and if a change is present you will detect it pretty > easily... of course if you need to know which thing changed then you > need to cache the entire block, which is mostly what config.xml is > doing, but splitting that file up makes sense, to leave the scripts > and resources where they are and make a config.xml for youtube.com > <http://youtube.com> that can be easily voided or tested for and only > pertains to scripts that run on that site. Then the oversized > config.xml is no longer an issue.
> On Wed, Mar 17, 2010 at 10:15 AM, Kwah <kwa...@gmail.com > <mailto:kwa...@gmail.com>> wrote:
> On 17 March 2010 12:59, Anthony Lieuallen <arant...@gmail.com > <mailto:arant...@gmail.com>> wrote: > > On 03/16/10 18:11, Kwah wrote:
> >> .. As for the multiple @requires, rather than store them in the > >> directory root, perhaps ..
> > And existing installs? Migration is difficult at best.
> Check if config.xml currently exists. If so,continue to obey it ('as > normal') until it is no longer needed (due to reinstallations / > uninstallations). > For all new script installs, do not update/use the config.xml file and > use the 'new'/alternative config.xml-free solution.
> I admit that it is a messy solution during the transition (which I > suppose could never end in some circumstances) but will eventually > wean the people that this will affect most, away from config.xml quite > quickly. By 'the people that this will affect', I mean those that > regularly install / edit scripts.
> To affect everybody, would it not be possible to just restructure the > filesystem automagically after the updated GM install based on whether > config.xml is present (with permission from the user, of course)? > If a manual trigger (or both, for those who initially say no) is > preferred, add a button somewhere (with appropriate warnings) to > trigger the restructuring? Perhaps a 'refresh metadata'-type message.
> By 'restructuring', I mean having the script do what would effectively > 'reinstall' the script according to the 'new' structure (minus > config.xml data) *but* if the @require/@resource'd files are already > present on the filesystem, just move them (instead of downloading > them) in order to preserve any modifications already made.
> If new files need to be downloaded, a prompt stating that gm cannot > obey the 'new' metadata cannot be obeyed due to the files not being > present on the current install, would you like to download them? (I'm > not sure how to work in the warnining that this may change/break how > the current script functions though).
> >> .. have the script rename the @require/@resource files where > >> conflicts occur and have something similar to a config.xml in each > >> script dir ..
> > And then when the file is edited, what? The script author has > to know to > > open up this other file and edit it too?
> I was imagining this extra file would be present *only* when conflicts > occur and is used internally to "remember" which file is which. This > wouldn't protect against file renames of the conflicting > @require/@resource's, but doing that on the current version without > editing config.xml breaks things too.
> Do you have any data about how many people this might affect? From > current experience I would suggest that conflicting > @require/@resources are rare but I may have just been lucky to have > never been affected by it.
> > And how do we reconcile existing > > installs?
> "Import" it from the existing config.xml?
> -- > You received this message because you are subscribed to the Google > Groups "greasemonkey-dev" group. > To post to this group, send email to > greasemonkey-dev@googlegroups.com > <mailto:greasemonkey-dev@googlegroups.com>. > To unsubscribe from this group, send email to > greasemonkey-dev+unsubscribe@googlegroups.com > <mailto:greasemonkey-dev%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/greasemonkey-dev?hl=en.
> -- > You received this message because you are subscribed to the Google > Groups "greasemonkey-dev" group. > To post to this group, send email to greasemonkey-dev@googlegroups.com. > To unsubscribe from this group, send email to > greasemonkey-dev+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/greasemonkey-dev?hl=en. > Download thousands of great movies, for free! > http://click.lavabit.com/?r=MjM=
-- ? One out of every three Americans is suffering from some form of mental illness. Think of two of your best friends. If they are OK, then it must be you. ? http://tagzilla.mozdev.org v0.066
> On 17 March 2010 12:59, Anthony Lieuallen<arant...@gmail.com> wrote:
>> On 03/16/10 18:11, Kwah wrote:
>>> .. As for the multiple @requires, rather than store them in the >>> directory root, perhaps ..
>> And existing installs? Migration is difficult at best.
> Check if config.xml currently exists. If so,continue to obey it ('as > normal') until it is no longer needed (due to reinstallations / > uninstallations). > For all new script installs, do not update/use the config.xml file and > use the 'new'/alternative config.xml-free solution.
This sounds like a good idea, yes.
> I admit that it is a messy solution during the transition (which I > suppose could never end in some circumstances) but will eventually > wean the people that this will affect most, away from config.xml quite > quickly. By 'the people that this will affect', I mean those that > regularly install / edit scripts.
> To affect everybody, would it not be possible to just restructure the > filesystem automagically after the updated GM install based on whether > config.xml is present (with permission from the user, of course)? > If a manual trigger (or both, for those who initially say no) is > preferred, add a button somewhere (with appropriate warnings) to > trigger the restructuring? Perhaps a 'refresh metadata'-type message.
It might be good to just have a manual metadata refresh, or even leave that out in the initial release; in later releases, progressively add in a manual, an automatic with warning, and an automatic, as the code is proved mature. This would eventually eliminate the backwards compatibility problem (for all except old installs of GM being upgraded suddenly, of course; you'd have to keep around an automatic migration path for that).
> By 'restructuring', I mean having the script do what would effectively > 'reinstall' the script according to the 'new' structure (minus > config.xml data) *but* if the @require/@resource'd files are already > present on the filesystem, just move them (instead of downloading > them) in order to preserve any modifications already made.
> If new files need to be downloaded, a prompt stating that gm cannot > obey the 'new' metadata cannot be obeyed due to the files not being > present on the current install, would you like to download them? (I'm > not sure how to work in the warnining that this may change/break how > the current script functions though).
>>> .. have the script rename the @require/@resource files where >>> conflicts occur and have something similar to a config.xml in each >>> script dir ..
>> And then when the file is edited, what? The script author has to know to >> open up this other file and edit it too?
> I was imagining this extra file would be present *only* when conflicts > occur and is used internally to "remember" which file is which. This > wouldn't protect against file renames of the conflicting > @require/@resource's, but doing that on the current version without > editing config.xml breaks things too.
> Do you have any data about how many people this might affect? From > current experience I would suggest that conflicting > @require/@resources are rare but I may have just been lucky to have > never been affected by it.
> Just cache the config centrally in memory and check last access times, > as mentioned. (The access-time check can be parallelized, so as not to > delay load.)
Exactly.
My entire goal for this is to improve script authoring. Back when Greasemonkey was new, all users were script authors. I believe that no small reason for why it took off is because working with a Greasemonkey script is so easy: Just edit the file and reload the page. Bam. I think this is _really_ important.
But today, if you want to add an @require or @resource, this isn't enough. If you want to change the description or the name, a reinstall (at least) is required. It's clunky, especially when all that information is already right there in the script metadata. It's a poor system where the author has to know "you can edit this part of the file and it works, but changing that other part, which is really important when the script is installed, has no effect". And the workarounds.
But as mentioned, the cost of developing a backwards compatible solution, given (at least a bit of) my time invested in trying to make it happen, seems infeasible. Part of the cost is merging the @includes that are, now for installed scripts, stored in config.xml, those stored in the file, and not losing data.
I plan to spend a while thinking out possibly non-backwards-compatible options, and how drastic their impact might be.
On 17 March 2010 14:55, Sam <qufigh...@gmail.com> wrote:
> I'm thinking that abandoning some central config is a bad idea. What's > going to happen is you'll have to read every single script on every single > page you visit just to check if you need to include it or not? That doesn't > seem like an ideal solution unless this data is cached somehow, and thats > what it seems like config.xml is for in the first place... although when you > get a lot of scripts its too big to be fast.
I'm inclined to agree - it had been nagging at me re: without some kind of central reference how will GM discover which scripts to run.
> I like the idea of organizing > scripts based on the file-system because then if the directory youtube.com > doesn't exist there are no scripts to include for that site, but still if > you change an include in a script does it then need to be copied to a new > directory?
Just to make it clear, what I meant before about storage paths re:@require/@resource's was to have it like this:
<path to profile>/gm_scripts/script name/mainScript.js <path to profile>/gm_scripts/script name/conflicts.json <path to profile>/gm_scripts/script name/require/www.example.com/path/to/required/file.html
NOT
<path to profile>/gm_scripts/site/mainScript.js
> I really think centralized meta-data makes sense, the only > problem is knowing when to update it or if it hasn't changed and keeping it > as small as possible. If resources are only downloaded at installation time > then doesn't metadata about each resource need to be cached somewhere before > you'll know if they changed the path or updated, in which case you need to > download it again. Perhaps resources are in a separate directory structure > entirely from scripts and only downloaded if they don't exist or prompted > that a different version exists at update time.
How about changing the contents of config.xml? Or updating config.xml to include the last modified date/time of the main script file? That way, if GM checks the last modified timestamp of the main script (that contains the metadata), each time the script is run if the timestamp is later than the one in config.xml then the relevant checks for updates etc can be run.
> I think it is a big headache migrating if it's already reasonable ok how it > is now. I think that the metadata block should just be hashed or something > and if a change is present you will detect it pretty easily...
Storing metadata hashes means that the actual script's metadata must be hashed on every run of the script.
> of course if > you need to know which thing changed then you need to cache the entire > block, which is mostly what config.xml is doing, but splitting that file up > makes sense, to leave the scripts and resources where they are and make a > config.xml for youtube.com that can be easily voided or tested for and only > pertains to scripts that run on that site. Then the oversized config.xml is > no longer an issue.
I'm not sure that site-specific files would be better - I dread to think how many would be generated when combined with wildcards etc. Perhaps you can suggest a way to make this manageable?
> On Wed, Mar 17, 2010 at 10:15 AM, Kwah <kwa...@gmail.com> wrote:
>> On 17 March 2010 12:59, Anthony Lieuallen <arant...@gmail.com> wrote: >> > On 03/16/10 18:11, Kwah wrote:
>> >> .. As for the multiple @requires, rather than store them in the >> >> directory root, perhaps ..
>> > And existing installs? Migration is difficult at best.
>> Check if config.xml currently exists. If so,continue to obey it ('as >> normal') until it is no longer needed (due to reinstallations / >> uninstallations). >> For all new script installs, do not update/use the config.xml file and >> use the 'new'/alternative config.xml-free solution.
>> I admit that it is a messy solution during the transition (which I >> suppose could never end in some circumstances) but will eventually >> wean the people that this will affect most, away from config.xml quite >> quickly. By 'the people that this will affect', I mean those that >> regularly install / edit scripts.
>> To affect everybody, would it not be possible to just restructure the >> filesystem automagically after the updated GM install based on whether >> config.xml is present (with permission from the user, of course)? >> If a manual trigger (or both, for those who initially say no) is >> preferred, add a button somewhere (with appropriate warnings) to >> trigger the restructuring? Perhaps a 'refresh metadata'-type message.
>> By 'restructuring', I mean having the script do what would effectively >> 'reinstall' the script according to the 'new' structure (minus >> config.xml data) *but* if the @require/@resource'd files are already >> present on the filesystem, just move them (instead of downloading >> them) in order to preserve any modifications already made.
>> If new files need to be downloaded, a prompt stating that gm cannot >> obey the 'new' metadata cannot be obeyed due to the files not being >> present on the current install, would you like to download them? (I'm >> not sure how to work in the warnining that this may change/break how >> the current script functions though).
>> >> .. have the script rename the @require/@resource files where >> >> conflicts occur and have something similar to a config.xml in each >> >> script dir ..
>> > And then when the file is edited, what? The script author has to know >> > to >> > open up this other file and edit it too?
>> I was imagining this extra file would be present *only* when conflicts >> occur and is used internally to "remember" which file is which. This >> wouldn't protect against file renames of the conflicting >> @require/@resource's, but doing that on the current version without >> editing config.xml breaks things too.
>> Do you have any data about how many people this might affect? From >> current experience I would suggest that conflicting >> @require/@resources are rare but I may have just been lucky to have >> never been affected by it.
>> > And how do we reconcile existing >> > installs?
>> "Import" it from the existing config.xml?
>> -- >> You received this message because you are subscribed to the Google Groups >> "greasemonkey-dev" group. >> To post to this group, send email to greasemonkey-dev@googlegroups.com. >> To unsubscribe from this group, send email to >> greasemonkey-dev+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/greasemonkey-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "greasemonkey-dev" group. > To post to this group, send email to greasemonkey-dev@googlegroups.com. > To unsubscribe from this group, send email to > greasemonkey-dev+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/greasemonkey-dev?hl=en.
> > I think it is a big headache migrating if it's already reasonable ok how it > > is now. I think that the metadata block should just be hashed or something > > and if a change is present you will detect it pretty easily... > Storing metadata hashes means that the actual script's metadata must > be hashed on every run of the script.
After writing I was thinking that it would be simplest to 0) script has been modified 1) copied the metadata block into another file before, do it again soon 2) read the first n bytes of the script where n is the sizeof the metadata file 3) compare the last character, if the same, do a full compare 4) if its not the same then re-initialize the metadata block, and recache it
> > of course if > > you need to know which thing changed then you need to cache the entire > > block, which is mostly what config.xml is doing, but splitting that file up > > makes sense, to leave the scripts and resources where they are and make a > > config.xml for youtube.com that can be easily voided or tested for and only > > pertains to scripts that run on that site. Then the oversized config.xml is > > no longer an issue.
> I'm not sure that site-specific files would be better - I dread to > think how many would be generated when combined with wildcards etc. > Perhaps you can suggest a way to make this manageable?
I was thinking one config.xml for each domain to organize scripts based on some low level association with a particular site... i don't know how necessary it is unless your metadata file is huge... however I was thinking that there is some low level firefox knowledge of whether or not your domain changed during navigation, and that you only have to bother with a certain part of the initialization process when your domain changes, after that you already know which scripts could even possibly be associated with the site you're on. Sorting a single config.xml could have the same effect of letting you compare less, although I really don't know how it works now either.
Hope this is expresive enough to make for my lack of skill in english ( I am not native ).
I just want only two improvements, maybe 3.
1) Make reloading a script a single click task. This seems already work if you edit the script on his storing folder, but thats probably hiddeous, hacky and trickky.
2) Give the ultimate power to upgrade a script to the user. A website hosting a script can die, and the next owner of the site be a different person, untrusted, evil.
3) @requiere and such stuff sould be redownloaded wen a script is updated. Bonus points for detecting a change in the date of the script file and refreshing such files. This will make 1 user really happy (me), I don't know about the other millions of GM users.
4) Some standarization, so Greasemonkey script on browser A, runs on browser B.
I also have to say: thanks for all people involved in making GS the awesome piece of software that is today.
Haha, yes, I feel your pain. It could definitely use some work, but that's what we're doing here, no?
> Hope this is expresive enough to make for my lack of skill in english > ( I am not native ).
> I just want only two improvements, maybe 3.
> 1) Make reloading a script a single click task. This seems already > work if you edit the script on his storing folder, but thats probably > hiddeous, hacky and trickky.
Not really. Except that, as mentioned in this thread, some of the metadata is not properly reloaded. Other than that, it's the preferred method of editing scripts.
> 2) Give the ultimate power to upgrade a script to the user. A website > hosting a script can die, and the next owner of the site be a > different person, untrusted, evil.
This is possible, yes. At present, though, and for the foreseeable future, it's impossible for a script to update itself fully automatically, and I don't think there are any proposals for built-in fully-automatic updating, either.
> 3) @requiere and such stuff sould be redownloaded wen a script is > updated. Bonus points for detecting a change in the date of the > script file and refreshing such files. This will make 1 user really > happy (me), I don't know about the other millions of GM users.
They are redownloaded already on script update/reinstall, always. They are not redownloaded, at present, when a script is modified, for reasons given in this thread (and that's what we're trying to fix if possible).
> 4) Some standarization, so Greasemonkey script on browser A, runs on browser B.
This is mostly a matter of Opera, Chrome, Safari?, etc doing the right thing ;-)
On Mar 16, 10:59 am, Anthony Lieuallen <arant...@gmail.com> wrote:
> The files that @require lines are stored in are _usually_ identical to > the filename in the URL. But if two files of the same name (at > different hosts/paths) are referenced, it's no longer possible to know > for sure which file relates to which @require line. This gets extremely > hairy if they are edited later.
Well then you need to use the full path of the @required file and then just compute the hash of it and use that for identifying which @require references which file.
What if you insert a new line at the top of each file that is @requried, when its downloaded you insert a comment on the first line that has the original URL to the file. This would allow for a relatively speedy comparison. The data should be blocked out most likely so its easy to detect and separate from the file and unlikely that anyone will accidentally have already done this to their file. Then you can detect whether or not the file was @required using the new method rather easily. One could also cache the last known modified time for the file in this location...... If someone wants to hack with it and changes the URL thats at the top the worst thing that will happen is the file will be re-downloaded and reset I am imagining although it might not be that simple. If they want to hack the rest of it then a modification change can be detected and another flag could be added indicating that this required file is user modified post download..... then when updates occur you don't delete their file simply rename it.
On Wed, Mar 17, 2010 at 6:21 PM, sizzlemctwizzle <medleym...@gmail.com> wrote: > On Mar 16, 10:59 am, Anthony Lieuallen <arant...@gmail.com> wrote: >> The files that @require lines are stored in are _usually_ identical to >> the filename in the URL. But if two files of the same name (at >> different hosts/paths) are referenced, it's no longer possible to know >> for sure which file relates to which @require line. This gets extremely >> hairy if they are edited later.
> Well then you need to use the full path of the @required file and then > just compute the hash of it and use that for identifying which > @require references which file.
> -- > You received this message because you are subscribed to the Google Groups "greasemonkey-dev" group. > To post to this group, send email to greasemonkey-dev@googlegroups.com. > To unsubscribe from this group, send email to greasemonkey-dev+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/greasemonkey-dev?hl=en.
Scratch storing the modified time in the file to some extent, I'm not sure files are allowed to have that much self awareness or not. unless there is some low level way to say, if I put a magic character in a file it automatically inserts the time-stamp of the modification in that position? Its inherently dangerous to guess because one could cause an infinite update cycle pretty easily if you are too precise with the timestamp since I imagine the modified time for the file is set after the file is written and its impossible to write the actual modified time into the file itself although i could be wrong. I really want some other type of flag that is automatically set whenever the file has been changed on a low level in the system that you can reset manually which could be useful for any type of file that has a singular application. Nearest minute or second might suffice, but I would say make it at least ten seconds or else one could run into problems. I'm not sure anyone is quick enough to make a change within ten seconds of downloading it, so I think its important to consider the precision is really not that important and actually quite dangerously unimportant in this scenario.
On Thu, Mar 18, 2010 at 11:45 AM, Sam <qufigh...@gmail.com> wrote: > What if you insert a new line at the top of each file that is > @requried, when its downloaded you insert a comment on the first line > that has the original URL to the file. This would allow for a > relatively speedy comparison. The data should be blocked out most > likely so its easy to detect and separate from the file and unlikely > that anyone will accidentally have already done this to their file. > Then you can detect whether or not the file was @required using the > new method rather easily. One could also cache the last known > modified time for the file in this location...... If someone wants to > hack with it and changes the URL thats at the top the worst thing that > will happen is the file will be re-downloaded and reset I am imagining > although it might not be that simple. If they want to hack the rest > of it then a modification change can be detected and another flag > could be added indicating that this required file is user modified > post download..... then when updates occur you don't delete their file > simply rename it.
> On Wed, Mar 17, 2010 at 6:21 PM, sizzlemctwizzle <medleym...@gmail.com> wrote: >> On Mar 16, 10:59 am, Anthony Lieuallen <arant...@gmail.com> wrote: >>> The files that @require lines are stored in are _usually_ identical to >>> the filename in the URL. But if two files of the same name (at >>> different hosts/paths) are referenced, it's no longer possible to know >>> for sure which file relates to which @require line. This gets extremely >>> hairy if they are edited later.
>> Well then you need to use the full path of the @required file and then >> just compute the hash of it and use that for identifying which >> @require references which file.
>> -- >> You received this message because you are subscribed to the Google Groups "greasemonkey-dev" group. >> To post to this group, send email to greasemonkey-dev@googlegroups.com. >> To unsubscribe from this group, send email to greasemonkey-dev+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/greasemonkey-dev?hl=en.
