[Greasemonkey]

Aaron Boodman zboogs at gmail.com
Tue Apr 5 09:16:08 EDT 2005


Agreed. 

I was sorta thinking that the data would be in XML format. The
advantage is that XML can always be serialized, while only certain
objects in javascript can be. Also, with XML, the complexity of the
data is up to the script, while with key/value pairs, the complexity
is somewhat limited.

Some thought needs to be put into whether the data is
per-page/user-script, per-domain/userscript, or just per-userscript.

-- 
Aaron

On Apr 5, 2005 1:47 AM, Terry Alexis Lurie <tezza2k1 at yahoo.co.uk> wrote:
> Hi. It would be nice to store data that GM scripts could re-use.
> 
> There are two approaches which I have seen:
> 
> 1. Persist data using a local webserver and server side scripting using GM_xmlhttpRequest. So
>    GM_xmlhttpRequest({ method:"GET",
> url:"http://127.0.0.1:37777/persist_all_form_data.cgi?value="+data, headers});
> 
> 2. Use cookies.
> 
> There are problems with both approaches.
> 
> 1. a) server side persistent data needs knowledge of how to run a local web server
>    b) writing server side persistence cgis/jsps/servlets/asps et alia. requires knowledge outside
> javascript. Fine for those who know it, but I've seen many a talented DHTML person baulk at cgis.
>    c) persistent data is stored outside the administrative scope of your browser. You cannot
> within the browser, delete, alter or otherwise server side data. Unless there is a management
> page workflow, but see a),b)
> 
> 2. a) With cookies getting script cookie domain pathing data right is a pain. An example is
> writing a script for getting Glastonbury tickets, say. The purchasing site is spread over
> aloud.com, see-tickets.com and wayahead-secure.com. Unless you make a cookie for .com, then the
> cookie and the persistent data will not be available, although the target website has cross zone
> data itself.
>   b) There is no centralised place to manage client side persistent data
>   c) Greasemonkey data is difficult to differentiate from normal remote application cookies.
>   d) Remote applications wold have access to GM data.
> 
> Proposal
> --------
> 
> I appreciate there may be plans for this already, please clue me in.
> Greasemonkey is to have a hash lookup. An associative array to some.
> 
> To the script it would be:
>   - write: GM_persistSet('key',value);
>   - read: storedVal = GM_persistGet('key');
> 
> Then there would need to be a XUL front end manager to inspect, ammend, delete GM specific
> persistent data.
> This would be a lot easier if the store is accessed uniformly through known functions.
> 
> Who
> ---
> 
> I am planning to write these bits, if the consensus is that it is a good idea. Directions
> appreciated. I'm normally a J2EE, Perl, C++, Unix person, so it'll take some time.
> 
> Cheers,
> 
> Terry.
> 
> ------------------------------------------------------------
> Terry Alexis Lurie          | 'Something witty that doesn't
> Freelance Computer Engineer |  look good with variable
> United Kingdom              |  width fonts' - Most nerds
> _______________________________________________
> Greasemonkey mailing list
> Greasemonkey at mozdev.org
> http://mozdev.org/mailman/listinfo/greasemonkey
>


More information about the Greasemonkey mailing list