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.

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.

So Harry … you still in for a request queue ?

Let’s say I’m for AJAX frameworks providing APIs that help solve latency issues.

Queues are probably part of that, although there may be smarter ways to go API-wise (e.g. what Tibet does with workflows).

The thing is a “request queue” and a “response queue” (if those are the right names) would have to work in different ways;

A “request queue” would need to make sure that no additional requests are sent while any active request is still in progress (no response seen from server), to be able to guarantee that there’s no chance “message Y” arrives at the server before “message X”. That’s likely to hurt, performance-wise.

A “response queue” would be more about sequencing responses and making sure response callbacks fire in the right order that matches the sequence of outgoing requests.

There’s more to it than that though and what you need will depend largely on the feature you’re trying to build. Have this in head and may blog some other time.

One other thing – emailed Thomas Fuchs, the script.acul.us developer by way of explaination. Just dumping it here as I feel there’s a certain wrong in pointing out problems in other peoples code in the way I did;

Hi Thomas,

Just wanted to offer a quick word, in case you were wondering, with
what’s going on here
http://www.sitepoint.com/blogs/2006/02/10/ajaxlocalhost/ and here:
http://www.phppatterns.com/stuff/latency.html

Want to point out that I’m not trying to belittle what you’re doing.
In fact picked script.acul.us _because_ it’s a good project but
illustrates well some of the problems that haven’t been well solved
with AJAX yet. There are many other examples of AJAX online which
suffer similar problems, having failed to consider network issues
fully, and the purpose was to try to focus attention so we can fix
these problems.

I hope what I wrote in a later comment
(http://www.sitepoint.com/blogs/2006/02/10/ajaxlocalhost/#comment-13886)
serves as some consolation (there’s also my opinion on how to fix the
problem there);

“script.acul.us is actually some great code—other than the latency
issues, the way the autocomplete “widget” works client side is
excellent.”

Anyway, hope there’s no hard feelings and that you understand this was
done in the general interest of betterment of AJAX-style applications.

All the best,

Harry

Reply:

Heya,

I find the example a bit over-constructed, but you’re probably right
on the latency
issues in general.

I’d say that it’s a bug that should be fixed, but nothing special, as
it works fine most
of the time and autocompletion is an add-on to text input fields, not
an essential
functionality. Plus the autocompleter only issues requests to the
server after a specified
delay (with a reasonable default), so it _doesn’t_ call the server on
each keystroke.

So, latency really is a non-issue most of the time (at least with the
autocompleter),
but yes, it could freak out users when certain specific conditions
are met (in this
case strange proxy behaviour meets slow typing).

Can you file a bug on the ror trac?
http://wiki.script.aculo.us/scriptaculous/show/BugReports

And no, no hard feelings, good to see that Ajax (and thoughts on it)
are evolving
to make web apps better. :)

-Thomas