As a browser implementor, I don't think I would find this more useful than a boolean property indicating a connection is likely to be long- lived. I can't imagine doing anything more complicated than picking a threshold value to decide whether to count a request towards the connection limit and whether to consider pipelining requests on its connection. If all implementors did this, we'd likely end up with somewhat different threshold values, which would be unfortunate.

We could certainly agree upon and define the threshold values, that is trivial. However, would you want the threshold for connection limit counting and pipelining to be the same (as a boolean would effectively be)? I would think that are some responses that may take a long enough to avoid pipelining, but still count in against the connection limit. More importantly, pipelining is not simply a yes or no question, it is a question of which connection to pipeline on. A faster response is attained by pipelining on the connection that will be able handle the request soonest, and therefore pipelining becomes a comparison calculation. If browsers have numeric values for response time estimates, they can make appropriate comparisons and do optimal pipelining.

Perhaps the next iteration of browsers would only be based on thresholds, but numeric values allow great transfer of information, which could be used for more creative optimizations like pipelining comparisons and perhaps optimizations that we haven't even thought of yet. Just because we haven't foreseen all the possible optimizations, doesn't mean we shouldn't leave the door open for such optimizations. By allowing numeric values, authors can begin providing advice, and browsers can use it at their convenience.

Also, as I had mentioned in the proposal, there are situations where authors actually want to pipeline requests behind long-lived responses, so they are intentially not responded to. Once again, boolean values don't provide an adequate mechanism for communicated this desire.

Also, I'm skeptical that authors can estimate request latency with anything near that kind of precision. Thus, it is likely to be an unreliable source of information, meaning that the details of the value couldn't be trusted anyway, and even a high-low threshold might be unreliable. But most authors know if their XHR connection is intended to be used persistently, so the one bit of info would be more trustworthy.

Sure, it is impossible to create perfectly accurate estimates, and it is in fact an estimate and should be treated that way, but it seems very presumptious to assume that authors can't provide meaningful data. If authors don't know, that can simply not set this property or use a very high value to indicate a long-lived response. If they provide errant values, that is their problem, but I don't think we should understimate the potential of what authors can understand and do.


Reply via email to