Mostly holes - part 5: Rage against the machines

• The last post suggested, that all was clear now and just a bit of work was needed to get the project going.
• That was a misconception!

The problem

• The next step would have been to implement a server application, the browser plugin could connect to in order to get data and post retrieved information back to it.
• That's what you would call "Cross Site Scripting" and it isn't a nice expression...
• You could build a perfectly useful trojan horse using the same set of tools 
• That's why browsers have build in a "Same Domain Policy" (SOP) that let the AJAX scripting communicate only to the server/domain where it resides itself...
• You go to "http://amazon.de/someDirectory" and the site requests infos afterwards dynamically => It can only do that with http-Request going to "http://amazon.de/someOtherPlace".

Two ways - a fork

• The normal way to overcome this SOP is using a special XMLRequest called JSONP. That way, you can ... Just Do It (as Nike would say).
• Another way might be to go along with the SOP... and see, if the application can resign from calling the server all along. Instead the exchange with the server has to be done explicitly - whenever the user wants to get new data from others and check-in his own.
• And you can try to ignore the browser details ... just building your own browser that works differently

JSONP

• using JSONP, you would load a javascript function from a foreign server - that's OK with the SOP.
• this function only gives back a JSON object with the data, you want to transport
• since you want to get a dynamic response to a dynamic request (that might depend on the website, the user is on or on the content of HTML fields), the javascript URL, you incorporate ends with a "...?param1=value1&..." part -> a GET request with parameters
• The way, the javascript code gets incorporated might be a problem for plug-in-writers.
• The clippy-project already did something like that and it didn't work out ... making me restructure the javascript files and making them all locally available.

Loosely tied server interaction

• In order to have a persistent data set, a chrome browser plugin can use either localStorage - a new HTML5 feature to save more data than what was possible using cookies... or it could use chrome.storage (making a port of the plugin to other browsers even more difficult)
• Both options would build up a reasonable big data storage for the plugin and "Link", the cat might use this data when it gets into interaction at an arbitrary website, the user goes to.
• In order to sync with the net, you would surf to the server, requesting a website of the server.
• Here, the constraints of SOP don't apply anymore and we can exchange plugin and server data over XMLRequests ... hopefully
• ... there is still the issue that the website-javascript and the plugin-javascript are executed without any interaction - they only share the HTML-DOM
• That way, it might be necessary to use the DOM as an exchange medium.
• => Let's just say - it might work - it might not ... if this option is selected, the first thing would be a technical proof-of-concept to shift some data around ...

Hey, it's just a browser

• The last mentioned possibility seems quite absurd - building your own browser, just because you cannot cope with the ones already present...
• Perhaps, the work wouldn't have to be that big, since there have already been people that felt likewise:
• The Webkit project is open source and builds the base of the MacOS's Safari browser
• There are even people that try to give you a useful interface to act on the webkit browser and integrate it into your own C# application
• Having a full-fledged application instead of a browser plugin would make some things easier or even possible: The idea of placing the data in the DNS isn't really javascript compatible but might work out in a standalone-application.
• The big downside of a stand-alone application is, that nobody might use it - installing a plug-in and (almost) forgetting about it might spread the usage of SITA much more easily.

???

At the moment, I really don't know which path I should choose - if you feel like it, please give me some feedback. And if the vague goal isn't "clear" to you, please tell me so, too.