I am not sure that that the solution given for the autocompleter which consists in blocking newer transactions until the previous one has been completed is a good solution, since this is basically doing synchronous calls.

Guess it really needs trying. You brought up those magic words “it depends” like I’ve been trying to. Agree in general this is something like synchronous calling but for autocompletion, it may be the most effecient way. We also need to bear in mind that browsers place restrictions on the number of concurrent XMLHttpReqeusts (plus it costs resources).

The other issue there is also think sometimes a synchronous style is needed – if you want to make sure that requests arrive at the server in a given order, a simple approach is to have the client only send one at a time.

I have experimented with stack sequences (LIFO) with a queue size of 1. It guarantees that only the latest action of the user will be displayed (the other ones are discarded).

for instance if you type:

1—2—3

in one sequence, only ‘3′ will be displayed

If works fine, the only problem is that there must be a timeout so that requests do not block the entire sequence, indefinitely.

Been looking at what you’re doing and like it.

In general, I see this something like bank systems—there it’s not acceptable that any transactions get lost or processed incorrectly. To me “it works most of the time” isn’t enough, particularily because the tendency with AJAX is to couple the UI straight to the network.

Yes, I think it depends on the application. For an RSS feed reader it is OK that feeds get displayed in a random order. For every that involves transactions (bank system, …) there must be a transaction manager that enforces rules for how data is accessed.

I am not sure that that the solution given for the autocompleter which consists in blocking newer transactions until the previous one has been completed is a good solution, since this is basically doing synchronous calls.

I have experimented with stack sequences (LIFO) with a queue size of 1. It guarantees that only the latest action of the user will be displayed (the other ones are discarded).

for instance if you type:

1 – 2 – 3

in one sequence, only ‘3′ will be displayed

If works fine, the only problem is that there must be a timeout so that requests do not block the entire sequence, indefinitely.

Running the same demo without the Ajax Proxy or without the latency on the server gives totally different results, so I’d agree with Thomas that practically it may not necessarily be a problem.

Think you need to be very careful there. AJAX proxy is meant to simulate network effects that do happen. For example after the talk, someone listening told me they experienced more or less the same problem using the conference WLAN (that many people were using and many packets dropped through collisions).

Another network where you see really bad latency is mobile networks (not that AJAX is a good idea there anyway).

But this could effect any network. Even @localhost if you generate enough traffic, you may occasionally get requests and responses out of order.

In general, I see this something like bank systems – there it’s not acceptable that any transactions get lost or processed incorrectly. To me “it works most of the time” isn’t enough, particularily because the tendency with AJAX is to couple the UI straight to the network.

Although this autocomplete example may not seem serious, long ago I used to work at a courier company where users were entering data at intense speed via a DOS application (Joel Spolsky goes on about these type of apps from time to time), and “autocompletes” were essential to what they were doing. They trusted the autocomplete and moved so fast, when entering data, that I expect they would not have noticed “bogus” completions. If there had been “bogus” completions, that would typically have meant packages being sent to the wrong address.

in my experience so far, network latency must be combined with some latency on the server (one request takes 1 second, the other takes 2 seconds) for the problem to arise.

Running the same demo without the Ajax Proxy or without the latency on the server gives totally different results, so I’d agree with Thomas that practically it may not necessarily be a problem.