Following up on some of the Greasemonkey discussion, Christopher posted an alternate viewpoint on his blog. I found this section to be of interest:
The real question being discussed in Stephen’s comments is, “is there any benefit for service providers to support thirdparty ’scraping’ tools like Greasemonkey?” Maybe. But if there is, I say provide a cleaner API, instead of propping up ad-hoc solutions. Web development is ugly enough.
I think that one of the great things about Greasemonkey is that the service provider doesn’t have to do anything to support Greasemonkey scripts. While API’s are great, they often don’t provide the level of access Greasemonkey gives you1 and they are additional burden on the service provider.
I don’t think it’s really very difficult to be a Greasemonkey friendly service provider. Most good web front-end folks will create a naming convention for their HTML elements and stick with it, and if you acknowledge that people do use these scripts and are willing to be a little transparent when you make changes, you should be in pretty good shape.
- Does anyone know of a web application offered as a service that has an API that allows you to add buttons to the interface? [back]
Popularity: 4% [?]
Chris Griego adds this Comment:
How about A9.com Search and its implementation of OpenSearch and search channels?
June 26th, 2005 at 12:00 pm
Alex adds this Comment:
Um, how about it?
June 26th, 2005 at 5:24 pm
Chris Griego adds this Comment:
It, in effect, allows you to add buttons to the A9 interface.
June 27th, 2005 at 7:45 pm
Alex adds this Comment:
I wouldn’t say that is the same as what you can do with Greasemonkey.
June 27th, 2005 at 11:06 pm
christopher baus adds this Comment:
I guess you could look at xhtml as an API, and I see your point.
I don’t care that xhtml is a weird API that much, but web application developers currently don’t think that way, so xhtml documents are changed at whim. That’s something for greasemonkey users and developers to keep in mind.
June 29th, 2005 at 11:49 am