Sunday, April 24, 2005
Book Burro
Book Burro is wonderfully done work. Not only does it work well, but it's actually very visually pleasing (to my eyes, anyway). The only thing I find myself wanting is the ability to drag it around, but that's pretty minor.
Wiki Footer Fixer
Funny: Carlo Zottman, author of many user scripts indeed has added to the wiki what may be his best work yet: a greasemonkey script that modifies the greasemonkey wiki.
Saturday, April 23, 2005
Greasemonkey 0.3b Beta
Update: The XPI I posted was a) corrupted and b) not able to be served from youngpup.net (the classic XPI/mimetype issue). Sorry about the false start. Reposting now to mozdev.org. Will update again here when it is available.
If you like living on the edge, you may want to try out Greasemonkey 0.3b Beta.
The most noticeable user improvement is the addition of an "edit" button in the manage dialog and a little greasemonkey icon in the bottom right of the screen that you can use to disable GM quickly. Also, we now work on FF 1.0.3. Under the covers, developers now have access to GM_setValue and GM_getValue for persistent storage.
If you decide to try this version, please be aware that there is a pretty significant config migration that happens the first time it runs. You may want to back up your existing configuration before installing. Check the FAQ for details on where to find it.
As always, please report your bugs here, or on the mailing list.
If you like living on the edge, you may want to try out Greasemonkey 0.3b Beta.
The most noticeable user improvement is the addition of an "edit" button in the manage dialog and a little greasemonkey icon in the bottom right of the screen that you can use to disable GM quickly. Also, we now work on FF 1.0.3. Under the covers, developers now have access to GM_setValue and GM_getValue for persistent storage.
If you decide to try this version, please be aware that there is a pretty significant config migration that happens the first time it runs. You may want to back up your existing configuration before installing. Check the FAQ for details on where to find it.
As always, please report your bugs here, or on the mailing list.
Monday, April 11, 2005
Miscellaneous
Raddest user script yet: Lickr.
Jon Udell uses Greasemonkey as a DDOS platform ;-). Please be considerate with how much traffic you generate with scripts; the last thing we want is people seriously looking for ways to block GM.
More interestingly, he laments:
I cannot help with the former; that is up to web service operators to provide reasonable interfaces. On the second, what we really want is HTML overlays.
Were there no legacy concerns, the syntax might ideally look something like this:
<overlay insertbefore="/foo/bar[@monkey]">
<div>
... your html, css, javascript here ...
</div>
</overlay>
<overlay replace="//a">
... do something to all hyperlinks here ...
</overlay>
Clearly, this hasn't been totally thought out. But usually what people are doing in greasemonkey is adding, modifying, or replacing HTML. This might be easier to do with a declarative language, like, say, HTML.
Of course, there's nothing stopping you from doing this:
<overlay insertafter="/html/body">
<script language="javascript">
regular GM type code here...
</script>
</overlay>
... which just shows that this would essentially be a superset of current GM functionality.
What do people think of this? I see several problems, myself:
a) Implementing some of these overlay commands may require loading the entire DOM somewhere offline, pre-render, manipulating it, then feeding it to the renderer. This kills the progressive loading that browsers use to make page loading seem faster. It also sounds really, really hard. It would be easier to use regular expressions, instead of XPath, but that feels pretty hacky.
b) This model seems to conflict with one of GMs major current features, that it doesn't make visible markup changes to things like rich text editors. Maybe this could be gotten around by special casing RTE's and not running GM on them.
c) Somebody will undoubtebly say that I'm overthinking things.
Jon Udell uses Greasemonkey as a DDOS platform ;-). Please be considerate with how much traffic you generate with scripts; the last thing we want is people seriously looking for ways to block GM.
More interestingly, he laments:
"there are two aspects of [writing greasemonkey scripts] that feel antiquated. One is groveling around inside Web pages -- in this case, the Bloglines and del.icio.us citation pages -- using regular expressions. The other is groveling around inside the DOM (document object model) of the page into which you're inserting instrumentation."
I cannot help with the former; that is up to web service operators to provide reasonable interfaces. On the second, what we really want is HTML overlays.
Were there no legacy concerns, the syntax might ideally look something like this:
<overlay insertbefore="/foo/bar[@monkey]">
<div>
... your html, css, javascript here ...
</div>
</overlay>
<overlay replace="//a">
... do something to all hyperlinks here ...
</overlay>
Clearly, this hasn't been totally thought out. But usually what people are doing in greasemonkey is adding, modifying, or replacing HTML. This might be easier to do with a declarative language, like, say, HTML.
Of course, there's nothing stopping you from doing this:
<overlay insertafter="/html/body">
<script language="javascript">
regular GM type code here...
</script>
</overlay>
... which just shows that this would essentially be a superset of current GM functionality.
What do people think of this? I see several problems, myself:
a) Implementing some of these overlay commands may require loading the entire DOM somewhere offline, pre-render, manipulating it, then feeding it to the renderer. This kills the progressive loading that browsers use to make page loading seem faster. It also sounds really, really hard. It would be easier to use regular expressions, instead of XPath, but that feels pretty hacky.
b) This model seems to conflict with one of GMs major current features, that it doesn't make visible markup changes to things like rich text editors. Maybe this could be gotten around by special casing RTE's and not running GM on them.
c) Somebody will undoubtebly say that I'm overthinking things.
Friday, April 08, 2005
Userscript.org
I posted something very like this to the mailing list, but I wanted it to get out to more people for consideration.
So far, Greasemonkey has gotten by with a wiki page, but it's quickly outgrowing that.
So I'm starting to work on a new user script directory, which will live over on userscript.org.
I'm interested in input on how I'm planning to do this (or if someone would like to help). If you think I'm doing something wrong, please convince me.
To set the stage, here are the goals I'm attempting to address:
That's all fairly ambitious, so I'll be reluctant to take on new goals.
In order to serve goals 1-4, the directory will need to discover scripts, and regular spidering won't be very useful, I think, because there are relatively few user scripts, and I'm not sure how to go about finding good sources of scripts.
(Well, there are obvious things like checking domains you've found them on before, and taking outbound links from those sites if url like *user.js, but even so...)
I think using delicious for discovery is a pretty easy win, because people will tag for Greasemonkey if it's useful, and delicious is useful as a directory to start with, and we can seed the tagging with quite a number of scripts already.
Of course the directory will allow form-post submission of a URL to a script so that authors can have a more direct way of discovery.
So assume we've got a directory and it has lots of scripts and no trouble finding more.
I plan on managing versioning as follows: once a script has been discovered, it will be hashed, and this hash will be the basis for differentiating the originally retrieved script from any later version. Scripts in the directory will be periodically retrieved, and changes in hashes will create new versions in the directory.
Why take this route over allowing (read: requiring) authors to explicitly version?
1) Because this versioning is meant to allow not just for update notification, but also for assignment of trust. A popular script that has not changed in a month is very likely trustworthy, but once a new version is published, all bets are off. If the author controlled the versioning as well as the script, there'd be no basis for trust.
2) Because authors won't consistently version their own scripts. User script authoring is meant to be relatively fluid and lightweight, and making backups and renaming and re-versioning is a bunch of overhead when the author just wants to spend a couple seconds fixing a bug.
So assume we have a directory with scripts and versioning. With this, we can provide update notification. Syndication seems the obvious choice; it's lightweight, and people interested in Greasemonkey are very likely to use it. I suppose we could also do email notification, but, well, I don't know much about administering a mail server or mailing list software.
So the user's been notified that there is a new script he may be interested in. How does she know whether its OK to install? There've been suggestions that sand boxing user scripts would be good, and breathless descriptions of how this is the end of e-commerce (OK, that's a small hyperbole).
(Thanks to Adrian Holovaty for pointing out that Craigslist has this problem and has proven that a community review process is all you really need to keep bad things from happening.)
I think generally people will be interested in controlling this problem, and keeping stuff completely safe is sort of an impossible goal. All you can hope for is to keep things from going off the rails and exposing lots of people to rude things. We'll have people using these scripts, and some of them will peek under the hood, and some of -them- will notice that the script is doing rude things. These people should be able to flag scripts as evil, and a trusted group (perhaps recruited on the basis of correct flagging) will review a queue of flagged scripts. Anything sufficiently flagged (what's sufficient? I dunno) will be unavailable in the directory until it's reviewed. Anything that's been reviewed and has the Good Webkeeping seal of approval will be exempt from flagging (or have a higher threshold, or something complicated). Things reviewed and found to be evil will be banished from the directory, along with the IP subnet and country of author. OK, maybe just the script.
Along the same lines, I'd like to have a flag that says "doesn't work", and eventually, I'd like this to be integrated in GM's client so that when people say something doesn't work, we can have a list of injected scripts for clues as to script compatibility problems (because that really is a problem, and it's only going to get worse).
Further along trust lines, there's also the idea that a script that's been out unchanged a while and followed out and unflagged is probably a good and Good script, so those scripts might get some bonus in ranking. Which leads us into actually finding the script you're looking for.
There'll be full text search (so you can see how people are using GM_* functions or find a script through a comment), there'll be header search (show all scripts which match URL x, or have name y, etc). There'll also be a tag search, which will just use delicious' tags.
So now you've got some search results. They'll be ranked by number of delicious links to start with, and maybe that'll be good enough. If not, we can throw in trust or search noise, or something else complicated.
Also, particular script versions will be available off of stable URLs on the directory. The search results will take you to the original publishing location, but if your favorite ~user/script goes down, the directory will still be there. I haven't decided what the stable URL should look like. /root/namespace/userscript seems obvious, but of course, lots of people aren't setting their namespaces, so who knows. I also plan to have all versions available, so that if /root/namespace/userscript is current, then /root/namespace/userscript/20050110-164502 was the script as of that date and time (and it'll use the normal W3 date format, of course). I dunno, maybe this isn't version 1 stuff, but I think it'd be useful to see evolutions or to have a stable pointer for some discussion and such.
That about does it for goals 1-3. But assume you're a script author, and you'd like to share your script. You just post it on your site (Or submit it to the directory for hosting? This might get complicated.) Everyone knows where to find user scripts, so it's way out there, even if you're not an A-lister. And if you change something, everyone that wanted to know will know.
Another benefit of the hash approach is that the GM client could some day support auto update by hashing its installed script and asking the directory for any updates.
We also have a situation where authors modify functionality of scripts after publishing (say, to support UPS tracking after publishing a FedEx-only linker), and an accidental benefit of the wiki has been that script authors could say what changed easily. I'd like a @longdesc so that script authors could write a book (like this one!) about how great their user script is, and the directory would scrape this so that updated functionality just shows up in search.
That's up to goal 4.
Goal 5 is a bit broader, but I'm pretty stoked to see user scripts in Opera and IE. Safari already had Pith Helmet, and we apparently didn't inspire Opera, but I don't care. I just want user scripts to be useful and for them to spread, so I'd like to do what we can to provide a home for user scripts in general, and help other projects that don't have mozdev and mozillazine to help them with hosting and community. userscript.org will start out GM-only, but I hope that changes.
This last one is months or longer out, but it seems worth doing, and I'd like to do it.
Of course I don't plan on doing all this stuff before putting something out there, and I hope you readers will tell me what I'm doing wrong, but this is the general direction I'm headed.
If anyone got to the end, congrats, and please take a few more minutes to tell me how this could better, but please keep the goals listed above in mind.
P.S. There's already been useful discussion on the mailing list. If you're interested in this stuff, I recommend you join.
So far, Greasemonkey has gotten by with a wiki page, but it's quickly outgrowing that.
So I'm starting to work on a new user script directory, which will live over on userscript.org.
I'm interested in input on how I'm planning to do this (or if someone would like to help). If you think I'm doing something wrong, please convince me.
To set the stage, here are the goals I'm attempting to address:
- Provide versioning and update notification.
- Improve ability to judge trustworthiness of scripts
- Provide an easy way to find user scripts.
- Encourage sharing of scripts.
- Provide a home for the idea of user scripts, including other browsers.
That's all fairly ambitious, so I'll be reluctant to take on new goals.
In order to serve goals 1-4, the directory will need to discover scripts, and regular spidering won't be very useful, I think, because there are relatively few user scripts, and I'm not sure how to go about finding good sources of scripts.
(Well, there are obvious things like checking domains you've found them on before, and taking outbound links from those sites if url like *user.js, but even so...)
I think using delicious for discovery is a pretty easy win, because people will tag for Greasemonkey if it's useful, and delicious is useful as a directory to start with, and we can seed the tagging with quite a number of scripts already.
Of course the directory will allow form-post submission of a URL to a script so that authors can have a more direct way of discovery.
So assume we've got a directory and it has lots of scripts and no trouble finding more.
I plan on managing versioning as follows: once a script has been discovered, it will be hashed, and this hash will be the basis for differentiating the originally retrieved script from any later version. Scripts in the directory will be periodically retrieved, and changes in hashes will create new versions in the directory.
Why take this route over allowing (read: requiring) authors to explicitly version?
1) Because this versioning is meant to allow not just for update notification, but also for assignment of trust. A popular script that has not changed in a month is very likely trustworthy, but once a new version is published, all bets are off. If the author controlled the versioning as well as the script, there'd be no basis for trust.
2) Because authors won't consistently version their own scripts. User script authoring is meant to be relatively fluid and lightweight, and making backups and renaming and re-versioning is a bunch of overhead when the author just wants to spend a couple seconds fixing a bug.
So assume we have a directory with scripts and versioning. With this, we can provide update notification. Syndication seems the obvious choice; it's lightweight, and people interested in Greasemonkey are very likely to use it. I suppose we could also do email notification, but, well, I don't know much about administering a mail server or mailing list software.
So the user's been notified that there is a new script he may be interested in. How does she know whether its OK to install? There've been suggestions that sand boxing user scripts would be good, and breathless descriptions of how this is the end of e-commerce (OK, that's a small hyperbole).
(Thanks to Adrian Holovaty for pointing out that Craigslist has this problem and has proven that a community review process is all you really need to keep bad things from happening.)
I think generally people will be interested in controlling this problem, and keeping stuff completely safe is sort of an impossible goal. All you can hope for is to keep things from going off the rails and exposing lots of people to rude things. We'll have people using these scripts, and some of them will peek under the hood, and some of -them- will notice that the script is doing rude things. These people should be able to flag scripts as evil, and a trusted group (perhaps recruited on the basis of correct flagging) will review a queue of flagged scripts. Anything sufficiently flagged (what's sufficient? I dunno) will be unavailable in the directory until it's reviewed. Anything that's been reviewed and has the Good Webkeeping seal of approval will be exempt from flagging (or have a higher threshold, or something complicated). Things reviewed and found to be evil will be banished from the directory, along with the IP subnet and country of author. OK, maybe just the script.
Along the same lines, I'd like to have a flag that says "doesn't work", and eventually, I'd like this to be integrated in GM's client so that when people say something doesn't work, we can have a list of injected scripts for clues as to script compatibility problems (because that really is a problem, and it's only going to get worse).
Further along trust lines, there's also the idea that a script that's been out unchanged a while and followed out and unflagged is probably a good and Good script, so those scripts might get some bonus in ranking. Which leads us into actually finding the script you're looking for.
There'll be full text search (so you can see how people are using GM_* functions or find a script through a comment), there'll be header search (show all scripts which match URL x, or have name y, etc). There'll also be a tag search, which will just use delicious' tags.
So now you've got some search results. They'll be ranked by number of delicious links to start with, and maybe that'll be good enough. If not, we can throw in trust or search noise, or something else complicated.
Also, particular script versions will be available off of stable URLs on the directory. The search results will take you to the original publishing location, but if your favorite ~user/script goes down, the directory will still be there. I haven't decided what the stable URL should look like. /root/namespace/userscript seems obvious, but of course, lots of people aren't setting their namespaces, so who knows. I also plan to have all versions available, so that if /root/namespace/userscript is current, then /root/namespace/userscript/20050110-164502 was the script as of that date and time (and it'll use the normal W3 date format, of course). I dunno, maybe this isn't version 1 stuff, but I think it'd be useful to see evolutions or to have a stable pointer for some discussion and such.
That about does it for goals 1-3. But assume you're a script author, and you'd like to share your script. You just post it on your site (Or submit it to the directory for hosting? This might get complicated.) Everyone knows where to find user scripts, so it's way out there, even if you're not an A-lister. And if you change something, everyone that wanted to know will know.
Another benefit of the hash approach is that the GM client could some day support auto update by hashing its installed script and asking the directory for any updates.
We also have a situation where authors modify functionality of scripts after publishing (say, to support UPS tracking after publishing a FedEx-only linker), and an accidental benefit of the wiki has been that script authors could say what changed easily. I'd like a @longdesc so that script authors could write a book (like this one!) about how great their user script is, and the directory would scrape this so that updated functionality just shows up in search.
That's up to goal 4.
Goal 5 is a bit broader, but I'm pretty stoked to see user scripts in Opera and IE. Safari already had Pith Helmet, and we apparently didn't inspire Opera, but I don't care. I just want user scripts to be useful and for them to spread, so I'd like to do what we can to provide a home for user scripts in general, and help other projects that don't have mozdev and mozillazine to help them with hosting and community. userscript.org will start out GM-only, but I hope that changes.
This last one is months or longer out, but it seems worth doing, and I'd like to do it.
Of course I don't plan on doing all this stuff before putting something out there, and I hope you readers will tell me what I'm doing wrong, but this is the general direction I'm headed.
If anyone got to the end, congrats, and please take a few more minutes to tell me how this could better, but please keep the goals listed above in mind.
P.S. There's already been useful discussion on the mailing list. If you're interested in this stuff, I recommend you join.
Subscribe to:
Posts (Atom)
