Techhawking

The same origin policy prevents document or script loaded from one origin from getting or setting properties (XMLHttpRequest) of a document from a different origin. The policy dates from Netscape Navigator 2.0. This is a very important security restriction which disables rogue third-party javascripts from getting information from your authenticated banking server session.

Unfortunately, this also almost completely shuts down any possibility of data sharing between multiple servers. Note the use of the word “almost”, because “JSON” is the new Saviour of web2.0 world. JSON or Javascript Object Notation, is nothing but a simple data interchange format which can be easily used by javascript applications. Whats different here is that unlike XMLHttpRequest which can send back answers in any format the javascript application wants, JSON requires the answers to be in JSON format, which is basically a subset of Javascript Programming language, or to be more specific Standard ECMA-262.

For those who are curious how this works and don’t have time to read the complete documentation, the difference is that a javascript application can still call other javascripts to be loaded from third party websites. So if you are running an application on www.royans.net and you have some data on data.royans.net, you can load that data into your application as long as you masquerade that information as a javascript.

Thats it, there is no rocket science here… but it does feel like one when you first come across it. I surely did.

While you are at it, watch out for JSONP (JSON with padding) too. Google is one company which I know have been using such mechanisms for a long time. They recently came out with more vocal support of this new open data interchange standard.
Oh, and before you go hacking your code, one thing you might like to watch out is to avoid opening up private/privileged information using JSON mechanism, because its open to XSS (Cross site scripting hole).

The use of XmlHTTPRequest without refreshing the browser is one of the more common ways of differentiating an Ajax application from a more traditional approach. But while rest of the world was learning Ajax, some smart developers have figured out to do the next step and created something called “Reverse AJAX“, or as I call it “RAJAX”.

Traditional client-server applications (not over the web) which used standard TCP/IP and UDP protocols didn’t have to worry about Firewalls, NATs and PATs. Such client-server applications had the ability to intiate connections either way (from client to server, or from server to client). HTTP Protocol, which was built over TCP/IP was designed for specifically for web browsing where its always the clients asking for information and servers replying.

By moving traditional client-server applications to Web applications, the users did solve a lot of Firewall/NAT/PAT issues, but gave up a lot on usability and speed. AJAX to some extent solves the problem by reducing the amount of communication happening between the client ant the server, but it still doesn’t openly allow something which servers could do in the old client-server model. Initiate a connection back to the client.

RAJAX is a framework where multiple AJAX calls between the client and server could bridge this gap and give both the server and client the ability to ask and answer to requests. An excellent example of an RAJAX application is webified chat client. Google Talk for example doesn’t just open a connection when the user types in a message… it also keeps a connection open to the server to send messages to the user in case one of his/her contacts wants to initiate a chat. Another example provided by one of the reference links below is that of allowing multiple AJAX-based-document-sharers modifying the same document.
So, in short, the client always keeps an active HTTP request to the Server and allows the server to respond to that request only if there is a message from server to client which client didn’t ask for.

References

• http://ajaxian.com/archives/dwr-20-reverse-ajax
• http://prokata.com/reverseajax
• http://en.wikipedia.org/wiki/AJAX
• http://getahead.ltd.uk/dwr/documentation
• RAJAX

I’ve been out of the blogging world working on a ajax application which has been sucking out a lot of time from my already small free time which I have.

I’d mentioned Laszlo sometime back, and explained how its jumping into the Ajax world from a pure flash based application server. The ajax application I was working on, however, started in pure ajax before it got involved with Dojo. Dojo is not the only Javascript library out there, but it certainly is one of the better ones. I played around with a few others including yahoo’s javascript library, Google web toolkit and Sajax before I chose Dojo to work with. No server side code was one of the reasons, but its popularity was the man reason.

When I started off Dojo had 0.3 version out which already had a lot of important features like back-button-fix and keyboard event handlers which I heavily use in my application. As of today has 0.4 released which has among other things APIs to draw 2D graphics. But what really surprised me today was when I read that one of the most important things which wasn’t possible to do with javascript is now not only possible but its also supported by Dojo.

Interestingly, Offline storage on browsers has always been there in the form of web cache. I also know there are some flash based applications which can persist data on client’s desktop too… but until I saw the Dojo:Storage documentation it never occured to me that an Ajax based application could so easily use this feature to do something which should have been there to begin with.

Dojo doesn’t only have APIs to programatically recall that cache and browse the content but also interact and modify it. Here are some references to this interesting concept

• Adam Bosworth
• Take it with you Wiki
• Sample application Moxie using offline storage
• Brad Neuberg
• Dojo Storage
• Ajaxian about Dojo offline storage
• Zimbra working on offline application