[Greasemonkey] Goals for the user script directory (very long)

Michael Bierman greasemonkey at thebiermans.net
Fri Apr 8 03:11:17 EDT 2005


My comments preceded by "MB> " Please forgive the edits--I was trying to
remove stuff that I agreed with and wasn't necessary to repeat. :) 

-----Original Message-----
From: Jeremy Dunck

I'm open to suggestions, but I'm also writing code, so if you think I'm
doing something wrong, convince me.  :)

Goals:
1) Provide versioning and update notification.
2) Improve ability to judge trustworthiness of scripts

MB> What does this mean? People vote on their favorite scripts?  People can
leave comments? How do you define trust? How do you measure it? 

3) Provide an easy way to find user scripts.
4) Encourage sharing of scripts.
5) Provide a home for the idea of user scripts, including other browsers.

Assuming we can agree on these goals, here's how I plan to address them.

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.

MB> (see the end of this email for more on this). I think you may be trying
too hard again.  If you build a really good repository (or directory)
authors will list their scripts or users of scripts will add them for the
benefit of other users. Not everything has to be solved with a technical
solution, which a social one will do. :) This has the added benefit of being
self selecting in a good way--if authors don't list their own scripts, users
will--if they are encouraged a little bit...that helps better scripts find
distribution channels. 


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.

MB> Did you mean just the URL? Or the Url, description, mod date, script
name, more info (optional?), 

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).


MB> I think some of the reasons you want to do versioning (and hashing,
etc.) are very good--and definitely ambitious.  I still think that some
people will want to host their own scripts and a simple directory may
suffice here--but you have raised some good things to think about.

Michael





More information about the Greasemonkey mailing list