[LibX] Questions about libx

Jeremy Dunck jdunck at gmail.com
Fri Apr 28 10:16:33 EDT 2006

On 4/28/06, Godmar Back <godmar at gmail.com> wrote:
> The
> vast majority of scripts on that site did not work, or we couldn't
> figure out how to make them work (before you suspect incompetence, I
> have written and occasionally write GM scripts myself for various
> ad-hoc tasks, so I'm reasonably familiar with it. I gave up after 2, 3
> minutes for each script.)

I'm generally not quick to suspect incompetence, or even hold it
against people.  I am not well-skilled in all areas of human
knowledge, and so try not to criticise others for not being expert in
my pet interests.  ;-)

Even so, the issue you raise is well-known in GM-land.  There was a
major transition in the security model of GM such that many scripts
written under the old model don't work under the new model.  Mark
Pilgrim probably knows this best-- he had to port many scripts over
when writing Greasemonkey Hacks.

Lots of people see GM user scripts as shell scripts for the web, so
that it's no major hardship when one breaks-- just write a new one of
fix the old one.  This also implies a community assumption-- that
people using Greasemonkey are, largely, javascript developers.

And so I think the trouble with finding working user scripts is
largely a matter of bad presentation-- userscript.org should make it
easy to flag dead scripts and to update them with fixes.  Sadly, I've
never gotten around to that issue.

All that said, the issue is largely a cultural one, and it would be
entirely possible to have a well-tested set of userscripts as a
deployment unit.

> Such a degree of robustness would be unacceptable to many librarians -
> they definitely did not want to put their name (or logo) on such a
> piece of software.

I'm sure there are hundreds of working user scripts on us.o, but it's
not obvious which are which.  That's kind of the point-- there are two
things at work here.  There's the perception of GM's fragility and in
that sense, I think LibX is really in the same ballpark.  You're still
depending on DOM manipulation on a known tree-- you're just less
likely to break since OPAC upgrades are few and far between.  A user
script coded against an OPAC would be similarly stable.  ;-)

The second thing is that you're making a domain-specific page
modifier, and (as I hope I've made clear) I think that's useful.
(I also think it'd be nice if an library-related code library came out
of this.  Dealing with the various OPAC flavors, xISBN, OpenURL, and
COiNS could, I think, be usefully abstracted for extensions other than

> As far as your criticism of libx's internal goes, it is fully
> accepted.

I hope it's clear that I'm happy to see LibX, and that any criticism
I'm offering is rooted in my desire to see LibX's success.

I'd like to see the search interaction more stream-lined, too, but I
haven't formed a suggestion yet.   Copious free time...

More information about the Libx mailing list