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.
Thanks,
Kris
