On Mar 11, 2008, at 7:00 AM, Kris Zyp wrote:
for UAs is best approach, and that it should be a number-based
advice, not a boolean, so that it could be used more effectively
and flexibly in heuristic algorithms for making informed
pipelining decisions.
Can you be more specific in what you mean about "number-based
advice"? (Apologies if you explained this in an earlier message, I
tried skimming them and did not find a description).
I couldn't find my previous message in the archives, so I included
below again (sorry about posting it again). Basically I was
suggesting that a property (called "durability") could take a number
(rather than a boolean), that would represent advice about how long
the author expected the response to take. The user agent could
utilize this advice in any way it sees fit. A number provides more
information (a greater range of values) than a boolean, and it could
effectively be used as weighting in user agent heuristics. The
advice could be used by user agents to determine if the connection
should be counted against the connection limit (if it is larger than
a threshold), and it could used as advice for pipelining. The user
agent is not required to respond in any certain way, but this is
author provided advice, that the user agent may use in any way it
desires.
The advantage of a number may be more clearly seen in a pipeline
ordering example. Suppose I issue 4 requests, and I expect request A
to take a few milliseconds, request B to take a half a second,
request C to take a couple seconds, and request D could last
indefinitely. I could set different durability values for each XHR
request, and then the user agent could potentially use these values
(possibly in combination with other information, like connection
speed, proxy information, and so forth) to determine the order of
pipelining:
xhrA.durability = 0.01;
xhrB.durability = 0.5;
xhrC.durability = 2;
xhrD.durability = 100;
In this situation, a browser may decide to send A and B on different
connections, and send C as pipelined by request A. It may also
choose to send D on completely separate connection and not count
that against the connection limit. However, the advice does not
require the user agent to take any specific action, the browser can
weigh the advice in combination with other factors, depending on the
situation. Anyway, here is the more detailed proposal I had sent
out, I apologize if you have already received it/read it (it had a
subject "Re: Pipelining Control Proposal"):
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.
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.
Are there any implementors who would find an estimate of the request
latency more useful than a boolean "likely to be persistent" indicator?
Regards,
Maciej
