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
