4 ms·

It would be remiss to not mention Shawn Bracewell in the discussion. According to Alex Hopmann, Shawn was responsible for adding asynchronous support: "Step on

by Arjuna 13y ago

It would be remiss to not mention Shawn Bracewell in the discussion. According to Alex Hopmann, Shawn was responsible for adding asynchronous support: "Step one was to bring the code up to production quality so we got Shawn Bracewell, one of the devs on the OWA team to take it over. Being a smart guy he promptly threw away all of my code and rewrote it in a more solid fashion, adding async support, error handling and more." [1] [1] http://www.alexhopmann.com/xmlhttp.htm http://www.alexhopmann.com/xmlhttp.htm In addition, Jim Van Eaton wrote: "XMLHTTP was born and implemented by the OWA dev effort of Shawn Bracewell. Exchange funded the effort by having OWA development build XMLHTTP in partnership with the Webdata team in SQL server. XMLHTTP changed everything. It put the "D" in DHTML. It allowed us to asynchronously get data from the server and preserve document state on the client." [2] [2] http://blogs.technet.com/b/exchange/archive/2005/06/21/406646.aspx http://blogs.technet.com/b/exchange/archive/2005/06/21/40664...

ttrreeww 13y ago
http://www.linkedin.com/pub/shawn-bracewell/9/b23/a4 http://www.linkedin.com/pub/shawn-bracewell/9/b23/a4
kragen 13y ago
Sounds like Shawn Bracewell is the person to really credit — non-asynchronous XHR is unusable, and unused. Jim's remarks here are a little over the top. At KnowNow in 2000 we were asynchronously getting data from the server and preserving document state on the client by implementing Comet in in Netscape 4 (and IE 4), by using a frameset with zero-height frames. These days long-polling frames that finish loading when there's an event are more common, but we were using endless HTML documents that would get a <script> tag added when there was an event. The <script> tag would invoke top.somethingorother(data). A second invisible frame was used to send data back to the server as HTTP POSTs. We had a bunch of bodgy code to handle the case where you have several windows open doing Comet to the same server, ensuring you only ever have one persistent connection; otherwise the two-connections-per-server limit kicks in, and the page stops loading forever. It's more sensible to use wildcard DNS to circumvent this restriction. XHR is a much saner way to do AJAX, and Websockets are a much saner way to do Comet, but you can do AJAX and Comet without them. XHR didn't "change everything" and "put the 'D' in DHTML". It just made it more convenient.
- jeffbarr 13y ago
  Ah, the memories. I wrote the first non-KnowNow client for this data stream, at their request. For some odd reason best left buried in the sands of time, they wanted me to do it in VB6.
- kybernetikos 13y ago
  A comet server I work with still supports foreverframe for browsers without websockets or multipart-replace because for fast updating data, it's actually much more performant than long polling.
  - kragen 13y ago
    Sure, it performs better, but apparently there are a lot of network environments where long polling works and forever-frame doesn't.
    - kybernetikos 13y ago
      True. That's why polling is also supported as a fallback. Although with fast updating data, there's practically no difference between long polling and simple polling.
- derefr 13y ago
  > non-asynchronous XHR is unusable, and unused. I wouldn't say this at all. We could have gone in a completely different direction with Javascript, even back then: spawning numerous lightweight processes running userspace code which then sit in a blocking "receive" state whenever they want to wait for the result of an XHR. In other words, Javascript could have been Erlang for the browser, instead of the odd OS7-like cooperative-multitasking abomination we have now. (What we did get are Web Workers, which are full OS threads you can't even message if they're doing something synchronous. What's even the point of these?)
  - kragen 13y ago
    Sure, non-asynchronous XHR could have been usable. Opera at the time actually did give you multiple JS threads, but no locks or other synchronization primitives, so it was effectively unusable. We complained and, perhaps coincidentally, they "fixed" it by making it work like IE and Netscape.
BarkMore 13y ago
Starting with IE4, Internet Explorer provided an asynchronous interface for fetching URLs. If I recall correctly, you had to go out of your way to use the synchronous interface. It's great that somebody made XHR asynchronous, but it was just going with the flow of everything else in IE-land.

by Arjuna 13y ago

ttrreeww 13y ago

http://www.linkedin.com/pub/shawn-bracewell/9/b23/a4 http://www.linkedin.com/pub/shawn-bracewell/9/b23/a4

kragen 13y ago

Sounds like Shawn Bracewell is the person to really credit — non-asynchronous XHR is unusable, and unused. Jim's remarks here are a little over the top. At KnowNow in 2000 we were asynchronously getting data from the server and preserving document state on the client by implementing Comet in in Netscape 4 (and IE 4), by using a frameset with zero-height frames. These days long-polling frames that finish loading when there's an event are more common, but we were using endless HTML documents that would get a <script> tag added when there was an event. The <script> tag would invoke top.somethingorother(data). A second invisible frame was used to send data back to the server as HTTP POSTs. We had a bunch of bodgy code to handle the case where you have several windows open doing Comet to the same server, ensuring you only ever have one persistent connection; otherwise the two-connections-per-server limit kicks in, and the page stops loading forever. It's more sensible to use wildcard DNS to circumvent this restriction. XHR is a much saner way to do AJAX, and Websockets are a much saner way to do Comet, but you can do AJAX and Comet without them. XHR didn't "change everything" and "put the 'D' in DHTML". It just made it more convenient.

jeffbarr 13y ago
Ah, the memories. I wrote the first non-KnowNow client for this data stream, at their request. For some odd reason best left buried in the sands of time, they wanted me to do it in VB6.
kybernetikos 13y ago
A comet server I work with still supports foreverframe for browsers without websockets or multipart-replace because for fast updating data, it's actually much more performant than long polling.
- kragen 13y ago
  Sure, it performs better, but apparently there are a lot of network environments where long polling works and forever-frame doesn't.
  - kybernetikos 13y ago
    True. That's why polling is also supported as a fallback. Although with fast updating data, there's practically no difference between long polling and simple polling.
derefr 13y ago
> non-asynchronous XHR is unusable, and unused. I wouldn't say this at all. We could have gone in a completely different direction with Javascript, even back then: spawning numerous lightweight processes running userspace code which then sit in a blocking "receive" state whenever they want to wait for the result of an XHR. In other words, Javascript could have been Erlang for the browser, instead of the odd OS7-like cooperative-multitasking abomination we have now. (What we did get are Web Workers, which are full OS threads you can't even message if they're doing something synchronous. What's even the point of these?)
- kragen 13y ago
  Sure, non-asynchronous XHR could have been usable. Opera at the time actually did give you multiple JS threads, but no locks or other synchronization primitives, so it was effectively unusable. We complained and, perhaps coincidentally, they "fixed" it by making it work like IE and Netscape.

BarkMore 13y ago

Starting with IE4, Internet Explorer provided an asynchronous interface for fetching URLs. If I recall correctly, you had to go out of your way to use the synchronous interface. It's great that somebody made XHR asynchronous, but it was just going with the flow of everything else in IE-land.