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?


Reply via email to