RSS updates via your instant messenger

I thought this new web application immedi.at might be of interest to AJAX Blog readers. It only uses AJAX sparingly but it is written using Rails and offers a unique capability that may be useful to some: the ability to recieve update notices in any instant messaging client when an RSS feed of interest changes.

This is kind of cool for certain things because you don’t have to actively check to see if stuff has been added to certain feeds, they come to you. Like, I use it to monitor comment threads on some blogs as they develop and to get updates when I have new gmail messages.

Simulating Latency with Greasemonkey

Julien Couvreur has another approach to simulating network latency in AJAX apps - XmlHttpRequest - Add Latency. Certainly a neat solution in terms of lines of code Some random thoughts, perhaps to give Julien ideas.

When considering AJAX Proxy had half thought of Greasemonkey although figured an HTTP proxy is a more “honest” solution. Re-thinking, will probably work just as well with Greasemonkey.

Some specific things I wanted to be able to simulate with AJAX Proxy, with reference to Julien’s approach;

• Latency swings both ways. A delay could occur in the direction from client to server, sending a request. A delay could also occur from server to client, as the response is delivered. OK - that’s not exactly how the HTTP protocol works but from an application point of view, it makes a useful simplification.
  For example consider an AJAX chat application - there might be an operation on the server called “save message” which stores a single chat message sent in a request by a client. The response from the server to this operation is simply an “OK” or “Failed”. So what’s interesting is really any delay in the client to server direction. If the latency is varying over time (which it might), it could be possible that “Message A” and “Message B”, sent by the client, are received in order “Message B” then “Message A” by the server. The server needs to check the messages are stored in the right sequence (which implies the client is providing some kind of sequence information)
  Meanwhile another server operation, “get new messages”, is polled by the client to obtain new messages after a certain time or sequence ID - varying delay in either the server to client direction or vice versa causes new messages to be received by the client in the wrong order; the client also needs to check the order of what it receives.
  At the moment Julien’s solution is only delaying messages in the client to server direction - the delay he uses is inserted before the request is actually sent. Think it also needs to be possible to have a delay inserted after the response was received from the server but before the corresponding callback function is executed ( that’s going to dramtically increase the lines of code required though).
• Latency may vary over time. Julien uses a consistent delay, which will highlight painful end-user experiences but as the above point illustrates, it’s more subtle than that. On a typical network would get “spikes” and similar that mean things like for half a second response times are really bad but then recover. Depending on what you’re doing with AJAX this may mean you need to implementing “queueing” or sequencing - the Starbucks factor.
• Latency is not predictable. Basically the same point as above but would be nice if Julien’s solution supported “randomness” as another mode of testing.
• Sometimes it just fails. And a request might fail to get to the server or a response might fail to get back to the client - complete network failure somewhere down the line. From what I’ve seen with AJAX Proxy, when completely dropping requests and responses, the current browser XMLHttpRequest implementations do little, if anything, to report this to the caller (or callback). And from testing a few online AJAX demo’s (I’m avoiding naming names here but I’m sometimes sorely tempted) this will mean data loss for some apps.

Think it should be possible to simulate all of those conditions with Greasemonkey, although it’s a fair amount of work. Wish Julien good luck with it.

At some point will give AJAX Proxy a decent CLI startup interface (rather than having to hack the code) and package it with py2exe but right now, no time.

Another angle someone should look at is fiddler, which is basically AJAX Proxy but a lot better (Windows only though). Check out this forum post - should be possible to implement all of the above with JScript and fiddler.

Question: Is all this really a problem? We all care about accessibility, right? Well this is accessibility in the literal sense. You need to leave localhost realise this is a real problem - take a holiday to South Africa then try accessing your AJAX app over in the States. Failing that, make a friend of a South African - you may learn some new swear words.

AJAX Proxy 0.2

Version 0.2 of of AJAX Proxy is out - available here. This one actually passes on the POST body (duh).

The basic instructions on setting up Python are the same, as described earlier.

Configuration of the script has now changed - at the end of the script you would modify;

[code lang=”python”]
if name == ‘main’:
REAL_TIMEOUT = 10 # Timeout between AjaxProxy the remote host
# If you’re behind a proxy server yourself, use these
#PROXY_HOST = ‘proxy.server.com:8080′
#PROXY_USER = ‘yourusername’ # Not required
#PROXY_PASS = ‘yourpassword’ # Required if PROXY_USER is set
LOG_DOMAIN = ‘localhost’ # Restrict logging to this domain
LOG_FAVICON = 0 # Log requests for favicon.ico
PI.load(’proxy.instructions’) # Load the instructions file
[/code]

The instructions file allows you to tell the proxy how it should delay requests. An example;

[code lang=”python”]
# On each line, enter two instructions seperated by whitespace
# The first is executed after a request has been received by the proxy but before it forwards it
# The second is executed after the response has been fetched by the proxy but before it returns it to the browser

# The available instructions are;
# wait < creates a delay
# - the delay can be specified a colon then an integer (seconds up to 10)
# - or the word "random" for a random delay of 0 - 10 secs
# fail < the request or response fails - nothing delivered
# end < just outputs a message saying it’s the last instruction without interfering with the request for info only
# - use of this is optional

wait:0 wait:1
wait:random wait:random
wait:10 wait:10
wait:0 wait:0
fail # no need to define a response instruction
end
[/code]

Each line of instructions is used to apply to a single request / response lifecycle. The next request will use the instructions on the next line.

Otherwise, it now dumps the complete request and response (HTTP headers and body) which can be handy for debugging.

A friendly explaination some other time. Meanwhile it’s interesting to try some of the AJAX applications out there - there’s some tails or madness, rage and data loss waiting to be told ( and JPSpan is not entirely innocent either) …

Synchronous Requests == BAD

This is one point where I agree strongly with the name AJAX - remember what that first letter stands for…

To grasp why, it’s worth seeing some examples and discussing which I’ve attmpted before here.

In essence, when you make a synchronous call with XMLHttpRequest, everything else stops and waits for the request to complete. And that means everything - even any intervals you’ve set. You can’t even abort() the request via the readyStateChange property (don’t believe me? try and watch a [browser dependent] crash…).

In other words submitting a synchronous request puts you at the mercy of the network and the server you’re making the request to. While developing on localhost, you’ll probably be unaware of this and living under the illusion that synchronous requests are just fine. But on a live site, if the server happens to get Slashdotted, while you’re busy SJAXing, expect a very long wait and a dead browser - to an end user, particular when using IE, it looks like it’s crashed (if I remember right IE does eventually recover but only after about 5 minutes).

To really get a feel for this you need to see it in action, which I’ll do with the help of a simple Python HTTP server that only accepts on request at a time, then goes into a sleep for 10 seconds before serving the next request. Any other incoming requests have to wait until the server is free to continue working. This sort-of-simulates a web server that’s got too much work to do.

Note if you’re using Windows and don’t have Python installed, do so - it’s completely painless. Make sure you add the python executable to your PATH (i.e. Start > Control Panel > (Administration) > System > Advanced > Environment Variables and add C:\Python24\ at the end of the PATH variable).

The code for the server is simply;

[code lang=”python”]
#!/usr/bin/python
# minimal web server. serves files relative to the
# current directory.
#
# See: http://effbot.org/librarybook/simplehttpserver.htm
# http://docs.python.org/lib/module-SimpleHTTPServer.html
# http://docs.python.org/lib/module-SocketServer.html
#
# IMPORTANT QUOTE:
# “[the basic SocketServer implementations] process requests
# synchronously; each request must be completed before the
# next request can be started.”

import SimpleHTTPServer
import SocketServer
import time;

PORT = 8000

class MyHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
def do_GET(self):
SimpleHTTPServer.SimpleHTTPRequestHandler.do_GET(self)
# Go to sleep for 10 secs after serving request
time.sleep(10);

httpd = SocketServer.TCPServer((”", PORT), MyHandler)

print “serving at port”, PORT
httpd.serve_forever()
[/code]

Put this in some directory on your filesystem, in a file named server.py. Now add another file called response.txt to the same directory, containing simply;

[code]
Hello World!
[/code]

Finally add a third file called ajax.html to the same directory, containing the following;

[code lang=”xml”]

Do it!


[/code]

With that done, you can now fire up the server script - run server.py. For Windows users that’s something like;

[code]
C:\path\to\server.py
[/code]

If you put the python executable in your path or;

[code]
C:\Python24\python.exe C:\path\to\server.py
[/code]

if you didn’t.

The server is now listening on port 8000 so you should be able to access from your browser via the URL http://localhost:8000.

Follow the link to the ajax.html. Now click “doIt” a few times and see what happens - sometimes you’ll get a quick response (an alert that says “Hello World!”). Other times you’ll get a longish wait, during which your browser will be hung up. Now imagine users starting to fidget…

Then, to really see why synchronous requests are a bad idea, try running Apache Benchmark at the same time (it’s provided with Apache 2 as an executable for Windows users) e.g. from a DOS box;

[code]
C:\Progra~1\Apache2\utils\ab.exe -n 50 http://localhost:8000/response.txt
[/code]

Now try clicking on that “doIt” link a few times. Is this something you really want your users to experience?

Otherwise, another thing to try to really grasp the difference between synchronous and asynchronous requests is watching code execute with Venkman.

The bottom line here is remembering the Internet has instability built in - it’s a network you don’t control and can (and will) vary in percieved responsiveness, like when they release the verdict on Michael Jackson, complete with video.

The only two possible exceptions I’d make to this are for an Intranet application, where the end users are in shouting distance, or perhaps in the special case of a sychronous multipart requests (work work only in Mozilla anyway) - see this Sync Multipart demo and notice how the browser “recovers” while the request is still in progress.

So, to repeat, Synchronous Requests == BAD.