On Monday 01 May 2006 11:30 pm, kmcoleoz wrote:
> > > I believe that I read the IE <= 6 is restricted to 2 concurrent
> > > XMLHttpRequest calls at a time.
> > It's not exactly IE <= 6, it's the HTTP specification that suggests
> > that
> > no more than 2 concurrent persistent connections be open to the
> > same web server. See section 8.1.4 of RFC 2616:
> > http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.4
> > This isn't restricted to XHR requests, but all requests.
This relates specifically to HTTP 1.1 connections. IE bumps the limit to
4 connections when dealing with HTTP 1.0 and Mozilla always has a
"soft" limit of 2 with a hard limit of 4 where 2 of the connections are
allocated to a pool of longer-running requests and 2 are for "normal"
> Cool, thanks for the specific reference. This then makes my wish for
> an array of objects managed by connection manager even more viable,
Why? The network stack is going to manage this stuff better than you'll
be able to, unless the goal is to be able to garuntee return order.
Writing this kind of abstraction on top of the async primitives is very
straightforward in a language (like JS) that supports closures. Dojo's
dojo.io.queueBind() is less than 50 lines.
BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723