Re: multipart, server-sent events, and

> Since the breakage is caused in at least some cases by proxies, it is  not 
> in general safe to let XHR users opt in since they may control the  origin 
> server but generally would not control whatever proxies are  between the 
> server and the user.
>
> Pipelining is a great potential performance improvement and it's sad  that 
> it can't safely be used on the public Internet right now, so I  hope we 
> someday find a way out of the impasse.

There is a world of difference between browsers choosing to do pipelining 
where no one gets to opt-in, and XHR opt-in where developers know the origin 
server, may even know the full route for all users (as in intranets) and can 
make the calculating risk of where they want to try pipelining or not, and 
can even code backup solutions when pipelined requests fail. It seems very 
presumptious to tell developers that can't take that risk. Why not tell them 
they can't use XHR at all, since there are old browsers out there don't 
support XHR? Because developers should be given the opportunity to make this 
decision. Developers have chosen to use XHR even though there are browsers 
that don't support it, and this has led to progress. If they experience too 
much pipelining failure they can choose to opt-out. I am very skeptical that 
at this point the failure rate is high enough that very many developers 
would opt-out.
Ironically, this is probably our best opportunity to get through this 
impasse. If web developers can selectively turn on XHR, the few remaining 
proxies out there that break under pipelining will start to be singled out, 
and more likely to be fixed which in turn will create the pipeline 
reliability for browsers to use it more broadly.
Kris

Received on Tuesday, 19 February 2008 04:29:42 UTC