Wednesday, December 2, 2009

loadXML,load(uri),load(dom) sync or async ?

This post is to clarify some of my statements presented in webreflection blog comments (do not want to waste your space Andrea).

"Official Documentation" (more cookbook than API specification)

Question: is it guaranteed by "specification" that dom.loadXML is blocking regardless on dom.async property ? Do I have to write dom.async=false to perform intentional synchronous load of xml string ?

(not)Final Note

Since I have failed to "clearly" decrypt the documentation wording to come up with presentable argument I provide tests: Experiments show that current implementation of MSXML (all tested versions) show:
  • async=false - load(uri) - IS BLOCKING
  • async=true - load(uri) - IS NONBLOCKING
  • async=true - load(dom) - IS BLOCKING (logical ?, documented ?)
  • async=true - loadXML(string) - IS BLOCKING (logical ?, documented ?)

Usage of onreadystatechange is available in both async, and sync modes.
Would you write different code for load(uri) and load(dom/stream) ?
I do not.

For intentionaly synchronous code I will write async=false before any load (loadXml/load(dom)/load(uri))
and will continue processing after load exits (even if "runtime behavior" shows async=false as unnecesary for loadXml/load(dom)).

For intentionaly asynchronous code I will write async=true before any load (loadXml/load(dom)/load(uri))
(even if it's default) and will use readystatechange, and will not rely on load blocking (even if "runtime behavior" show that loadXml/load(dom) blocks).

Argument that loading string cannot be asynchronous is naive, anything can be made asynchronous even i++ if component designer decides to be and language + runtime features alow that ;-)

No comments:

Post a Comment