On 11 March 2010 19:08, Fracture <[email protected]> wrote: > I think an extension will suit your purposes better, especially if > you're looking at 300kb/10 days. If you run it for a year, that's > almost eleven megs sitting in prefs.js - my current settings take up > 336kb. Extensions can write files to disk rather easily. > > https://developer.mozilla.org/en/Code_snippets/File_I%2F%2FO > > And I think you meant GM_setValue, not GM_log.
Oops yeah, my mistake ;) Yeah, an addon is the route that I'm starting to get drawn to. Note btw, realistically I don't expect that it will run for a year in one go. If you'll excuse the shameless plug, what im actually looking to do is create what I suppose will eventually become a referral management tool for a very popular (legit) ptc site [1]. For anybody that is interested and is wants to find out more about its legitimacy etc, I suggest that you do your research and you hunt through google with terms such as 'neobux scam' and the likes and I can almost guarantee that you'll find very few complaints (the reasonable kind, not ones from people who expect it to be a get rich quick thing and quit after a couple days, eg). Oh, and then when you're done, don't forget to use my referral link [2] to join up ;) . On 11 March 2010 22:21, esquifit <[email protected]> wrote: > Do you intend to also *read* the data into the browser, or is it > enough if you just save the information to a local file? In the latter > case, you just could write the data as a text file to a new tab (via > GM_openInTab with a data: url) and press Crtl+S. > > It is admittedly not the most elegant design, but it has effort near 0 > and results near or equal to 100%. > (You know, when you grow older you start to think that way...) Anyhow, back to the actual topic... As I mentioned before in this message, its a referral management-type thing but to start with I just want to get the storage aspect correct before going for everything in one go. So to answer your question, yes I am going to want to read the data into the browser (but not just yet). I did the math recently and I calculate it to use ~120bytes per referral, per day (exact # depending on number of digits in the date, eg 1 vs 11, and whether the comma is included etc) and the first time a referral is 'archived'/'stored'/whatever, it uses approx 700 bytes (again, per ref and the exact # depends on the date etc yada yada). [nb, This confused me for a while but the initial volume isn't 10*120bytes because not everything has a 10day history to begin with ;) ] The second catch is that not all of the information is immediately available - some high level information is available in bulk, but the clicks are only available one referral at a time (contained inside an iframe) and I do not wish to automate this process as it would be against the site's unwritten rules about automation (though I suppose it could be classed under the bot category but that's a whole different discussion). I've uploaded to gist a "prettyfied" version (jsbeautifier.org) of the kind of thing that I'm currently storing. It is an example of one of the 'first load' referrals: http://gist.github.com/330959 yyyy/mm/dd type fields are updated daily (assuming the page is accessed / script is run on that date), where the actual/credited click data is available for up to 10 days. On 11 March 2010 15:22, Anthony Lieuallen <[email protected]> wrote: <snip> > I'd add: "provide a patch to Greasemonkey, such that GM_set values are > stored in a sqlite DB (one per script) rather than in preferences". That, > and SQL access to said DB has long been on the wishlist, but never high > enough to get attention yet. This is perhaps best talked about in a seperate message but how about something like one database but I've been (very briefly) looking at sqlite databases and one thing that jumps out at me is that data is not strongly typed but I'm not sure about how different this is to javascript on the whole / prefs.js however so perhaps this is a non-issue? I should probably test whether values are stored correctly but I'm lazy - is there anybody here that is knowledgable enough re:this to know if this is anything to worry about? <quote [3] > Note: SQLite is not a typed database, which means that any data type can be put into any cell, regardless of the type declared for the column and the database will attempt to convert it. Likewise, if you request a different type than the column type, SQLite will convert this value as well. </quote> [1] - http://www.neobux.com/ [2] - http://www.neobux.com/?r=kwah [3] - https://developer.mozilla.org/en/Storage ps, oops, sorry I thought that I had sent this before but it was sitting here as a draft =/ -- You received this message because you are subscribed to the Google Groups "greasemonkey-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/greasemonkey-users?hl=en.
