[Greasemonkey] I want persistent data

Terry Lurie tezza2k1 at gmail.com
Sun Apr 10 23:19:53 EDT 2005


Hi, I previously posted as tezza2k1 at yahoo.co.uk, but yahoo mail was
the suX0r for this and gmail is the r0X0R. At least by comparison.

I was making a case for client side persistence as well. Your idea for
augmented cookies is interesting.

> Quick specification:
> - Existing API "document.cookie": provides the script access (read and
> write) to the cookies in the current domain and path. Cookies that
> were set in a different domain are not visible. Cookies set outside of
> that path are not visible.

This is nice for cascading preferences, say. So a sub directory
[deeper page] has different preferences to that of a parent. But there
may be very many applications for which a quick and dirty datastorage
are more appropriate. This would be where the clientside script in
effect manages it's own data scoping.

The nice part of GM is that it allows javascript injection, a few
escalated privielege functions and an intuitive installation
management menu. All of this is easier than writing an extension from
scratch for most tasks.

If the persistence layer is more hierarchical, then I feel it would be
a step back towards the complexity of a browser extension.

> - New API "document.GM_cookie": provide the script access (read and
> write) to the cookies in the current domain for a specific path (maybe
> /greasemonkey/ or maybe some random GUID). These cookies "live" in the
> same browser cookie jar as regular cookies, but because they are set
> in a specific path, they are never sent to the server.

I like the idea of namespace overloading, which you've suggested here.
Previously I suggested a perl-esque hash storage, based around two new
GM_ functions

GM_storeValue('key',value);
and GM_getValue('key'); say

With your namespace overloading it would be the relevant read/write to
a place in the DOM, say greasemonkey.data.key. Once the user has
installed greasemonkey,  it is the new supervisor here. It soould not
be a sub-node of document in the DOM. There will be a lot of cross
i-frame communication that will not make sense to have under document.

I personally am not so worried about malicious GM scripts stealing my
pr0n passwords from other cookies. I also think that there will be a
whole cottage industry of XUL and purely client side scripts that
start appearing. These won't have a domain path as such, and the
utility of a cookie hierarchy will be less.

Take the example of a GM script tailoring rootNode.com, which  wants
to sum a setting in sub GM cookie domains. This is going to be hard
with hierarchical data managed by GM. Very easy if managed by the
script that needs to sum. This 'break out of the box' functionality
that GM is starting to provide should break the cookie mould here too.

But two different persistent mechanisms could be trialled of course,
that's the beauty. Then, if people complain their private cookie data
legged it to russia when then installed a dodgy user.js, we can
switch.


More information about the Greasemonkey mailing list