Re: Pipelining Control Proposal

How about I change the proposal so that there are no specifications about 
when pipelining should occur. The "pipeline" property would be purely used 
as a hint about which connection should be used if pipelining is performed. 
"should"/"should not" terminology would be used so that the pipeline 
controlling is not even an implementation requirement, but rather just a 
standardized way that the author can suggest to the user agent which 
connection is most advantageous to use as the pipelining target connection, 
if pipelining is used. This would provide the necessary information exchange 
such that the user agents could avoid the dreaded endless request queue, and 
could allow for advising on the creation of duplex communication. User 
agents could still choose not to pipeline, or even ignore the hint. This 
would be an extremely minimal addition to the XMLHttpRequest specification, 
and would have zero required implementation burden. Does that seem like a 
reasonable compromise?
Regardless of how you classify pipelining vs headers, XHR is still THE http 
client API for JavaScript authors, there are no lower level APIs available. 
With pipelining likely to become a more significant concern with high 
potential for hazard or benefit depending on pipelining control, this 
minimal addition seems like a good ROI. Would this approach be reasonable?
Thank you,
Kris

Received on Wednesday, 20 February 2008 00:00:05 UTC