Why again, is eValid superior for synchronizing based on DOM? I thought ANY JavaScript program could do that. So, what's the big deal?

The main class of applications for which synchronization is important is, as most eValid users know, those that are AJAX-based.

In AJAX -- where the operant word is Asynchronous -- the big question is, "How do you keep an automated playback from getting ahead of the application when the natural delay times are not long enough?"

Remember, when eValid records the session it keeps track of how long YOU took to respond to various AJAX activity and writes these "thinking time" values into the script. But relying on wait times for synchronization is not a good thing -- there ALWAYS is a time when the application is slow enough so that the recorded wait times are "not long enough."

The solution is to make the playback depend specifically on something that you see in the page, for example, a fragment of visible text, or to have the playback wait until something that you don't see but which is in the Document Object Model (DOM) of the page that has to be there for the page to be considered complete enough.

In the eValid architecture the synchronization commands that are available are all implemented as direct-execution type operations -- they don't in any way interfere with the operation of the JavaScript engine (that's the "J" in AJAX).

So, eValid is superior synchronizing because the synchronization commands are done "browser-direct" and don't rely on running JavaScript passages or anything like that which would interfere with the normal page behavior.

The eValid Team