Over the last week, I have taken almost every minute of my free time (minus playing Planescape: Torment...a lot) to work on upgrades to the WM system.
Make It Shine
One of the biggest issues WM has had since leaving Firefox 3.6 in the dust was its inability to then function on Google Chrome. If WM is to continue getting better, it really needs to work on all browsers, or at least those that generally follow some so-called standards. I personally believe that the proper implementation of HTML5 documentation is a goal all browsers should strive to achieve. For the most part, I think all the major browsers have done this except Chrome.
While close, Chrome's implementation is found lacking in the areas that are most important to WM, but why? Chrome's programmers go out of their way to provide you exceptional protection in a few departments, and one of those departments is the cross-domain attacks. I cannot talk down the job Chrome is doing in this department because its an important area to protect. In the past, cross-domain attacks have been a major plague on the internet as a whole. So if the Chrome staff decides that not allowing cross-domain-cross-window communication is a good thing, I can't fault them at all, even if every other browser allows it.
I just have to find another way. Before I put out any new version, WM must be chrome compatible.
Paranoia in the Barnyard
Over the last week, Ive come up with a few experimental systems to try and work around Chrome's known issues ...well, before I knew my work around didnt work around anything. My second effort showed great progress on the Firefox side, and because I thought Chrome was up to par with HTML5 implementation, I figured it would work like magic on Chrome as well. Um...no.
My intent was to avoid a complete revamp and just offer a new system through which sidekicks could communicate with the host script. While the new system works for Firefox, and improves some speed and how timeouts work, its still a kind of failure since it wont work on Chrome. This new system removed the need for sidekicks to post crap to the address bar, and for the host script to constantly watch the address bar. By opening a communication channel through HTML5's innovative postMessage function, I basically allowed the two windows to have a tin can telephone system instead of a PO Box.
Tin cans are better than a mailbox, but it can be even better. One thing about mailboxes and tin cans is that anybody can raid your mailbox, and anybody can hear you talking on the tin can line. One of the major improvements I was hoping for was to remove that born-in-the-barn kind of communication. What WM needs is a complete revamp of how sidekicks talk to the host.
My major reasoning behind this change is that FB and game hosts ARE listening to what you are doing. Its against policies, but to believe they are not listening is just plain stupid. Any modification to the document space, or even to the window space, is easily noticeable by other scripts running in those same realms. All they have to do is look for it. Calling you out in public could cost them their business, but calling you out by simply blocking you is within their blanket agreement's boundaries. Its a very wide and sprawling blanket if you really read the terms of service.
WM must live in a space where document level scripts cannot see it. WM must stay in that space and leave no trace.
To the Drawing Board?
Over the last few years, Ive been reading up on other methods to get data from one page to another using Greasemonkey. One of those ways I shunned was GM's ability to store data from one url and pick it up at another url running the same script. It seemed messy. The processor time it would require to listen for changes in stored data seemd too great. But then, this last week, I really started counting the milliseconds my other attempts were using; all the looping while waiting for pages to pass back that status code. The old method was the processor hog!
So its back to the drawing board for sidekicks.
Do No Harm
Its my intent, as always, to make any upgrades fully optional so that all past sidekicks will continue to work fully with any upgrade to the host. This system I just "finished" using postMessage would have been used by any sidekick with only an upgrade to the @required library file and the addition of about 5 lines of code to the script. Its my intent to accomplish that with my next plan, and hopefully those additional lines a script builder might need will number equal or less than this last attempt.
If I cannot get my new code to fit DDM's FV Sidekick, then it isn't good enough to use on anything else. I must protect that which is already created while writing new functions.
Any of you guys building scripts out there, fear not. It will be complete and documented when finished, and there will be little to no requirements on your part.