waelchatila.com - AJAX category

Turn your roomba into a walking google bot

Tue, 02 Mar 2010 07:26:00 GMT

When my latest son was born I got a little worried since he didn't look at all like me. I decided I needed a discrete device to spy on my wife while I was at work. I started hacking my roomba and made a GåågleBot (pronounced /google-bot/). GåågleBot is a "home crawler" consisting of a vacuum roomba with an on board webserver and camera. While the vacuum goes about its business, it extracts text from the images it takes. The text is later put in a database on the roomba and searchable through a web interface. This was a good pretext for my wife. I, of course, also added the ability to remote control the roomba using AJAX...for spying purposes...hehe.

I created a dedicated site for the little fellow for fun with showcase app. http://www.GaagleBot.com

This is the next version of My AJAX Lego Robot. I'm working on yet another version of my AJAX Remote Controlled thingies...stay tuned.

Internet Explorer 6 & 7 document.domain bug

Wed, 31 Oct 2007 17:25:00 GMT

Disclaimer: Im not sure this a bug discovery...couldn't find anything that resembled it after a couple of minutes of googling, or a super silly security restriction.

I've been coding some javascript ajax code that inserts an iframe, and into the created iframe, inserts a form and submits the form to a (cross domain) server. This is an old cross-domain ajax technique by now, but while implementing it I came across this ridiculously annoying bug in IE. The line in red below will result in an "Access Denied" exception being thrown...again, only in IE. Tried this with IE6 under WinXP Media Center Edition SP2, IE7 under WinXP Home Edition SP2, and IE7 Windows Vista Home. Needless to say...it works just fine in FireFox.

Try it by clicking the button below.

This page should be served off of http://waelchatila.com. As you can see, the document.domain is explicitly set to the domain the page was served from. The iframe src is also from the same server. I've tried it with a whole variety of variations, none of the demonstrated here but tested for.

iframe's document.domain = 'waelchatila.com';
iframe src is empty
iframe src is "javascript:false"

There should be no problem accessing the iframe's content in either case.

Now, if the document.domain = 'waelchatila.com'; line is removed, it works. In order for this to work, you'll need to reload this page if you clicked the previous button since document.domain has now already been assigned.

The same results present itself if the iframe is created with document.createElement('iframe') and document.appendChild(...)

I've yet to find a workaround for this issue. I'll be positing another entry if I found out how. Please let me know if you know of one!

AJAX Remote Controlled Lego Robot

Thu, 13 Jul 2006 11:00:33 GMT

This article shows how to remote control a real world lego robot using AJAX technology.

W AJAX design pattern

Sun, 09 Jul 2006 06:33:01 GMT

This is a new design pattern which was independently discovered by me and Will Glass over the phone one day while discussing a painful loading time of around 7 seconds for a web application we were working on.

Describing the problem

The web app front basically consists of a Google Map plus a form. The user can search for an address/place or, interactively on the map, select a boundary area for the search. When the search is submitted to the webserver, the webserver sends off an additional request to a 3rd party geodata server for the purpose of retrieving geocoding data plus demographical data. The problem is that this request to the 3rd party geocoding provider takes some time. The end result would be a wait for about 7 seconds between the time the search was submitted and the end resulting page showed up. The picture below depicts what’s going on 1. User submits a search request with HTTP POST
2. A blocking request to the geodata server is issued
4. Geodata retrieved and results are sent back to the browser
5. Data received by browser
6. Browser finished processing and rendering the data and page fully displayed.

W AJAX Solution

A way to reduce the response time is to utilize some AJAX. The idea is the following. When the search request arrives at the webserver, a new thread associated with the http session is spawned with the task to asynchronously do the 3rd party geodata request. Control is immediately returned back to the browser with no geodata. The browser, upon getting the no geocode data immediately sends of an AJAX request (asynchronous by nature) while it continues to render the web page with images, the Google Map, tables etc. This rendering takes some time to happen and by the time the rendering is done the AJAX request has landed at the webserver and is doing a blocking wait for the spawned geodata server request. When the 3rd party request is done, data is very quickly returned back to the browser (once again one of the natures of AJAX) and the rendered page is updated using DHTML. All in all reducing loading time, but more importantly reducing perceived responsiveness for the user.
The picture below with accompanying steps describes more in detail how it works. 1. User submits a search request with HTTP POST
2. A non-blocking request to the geodata server is issued in a spawned thread that is associated with the session. A web page layout with no geo data is returned to the browser.
3. Browser sends of an AJAX request with the purpose of retrieving geo data. Browser continues rendering the web page layout and elements.
4. AJAX request arrives at webserver and does a blocking wait for geo data to arrive. Geo data is finally calculated and results are sent back to the webserver. Webserver relays geo data to the AJAX request which returns.
5. Data is received by browser and presented in a quick manner using DHTML

Did it really work?

Was the rendering that bad? and is the extra complexity worth it? It depends on the situation and application. In our case we were able to squeeze down response time to around 3 seconds with the end result of a happy customer, in other words, it made a huge difference for us.

Why "W"?

The calling pattern traced out in the image above resembles a "W" and an "U", combine this with how "W" is pronounced in English and you get one visual "W" and, at least, one phonetic "U". Besides, it's arguable the best way to start a name, what do you think Will? :)

Using AJAX with CAPTCHA - AJAX Security Part 3 of 3

Mon, 19 Dec 2005 02:48:30 GMT

This article shows one way to use AJAX along with a series of images to create a secure CAPTCHA system. CAPTCHA is a way to tell humans and computers apart and is used all over the web, especially if you're signing up for new email accounts. For more background information and definitions, see http://en.wikipedia.org/wiki/Captcha