Date: Wed, 29 Jan 2003 10:01:57 -0800 (PST) From: Mark Crispin <[EMAIL PROTECTED]>
On Tue, 28 Jan 2003, Timo Sirainen wrote: > Sure. And I don't think I've said anything that would indicate otherwise. > The keyword in my comment above was *LESS* resource intensive. Using > multiple connections may be light, but using STATUS may still be lighter. NEVERTHELESS... The specification is explicit that there is no requirement that STATUS be fast. STATUS could be very resource intensive on a server, and there is *no* way for the client to know this. Therefore, a client MUST assume that STATUS will be resource intensive. Nonsense. A client should be implemented with the author's best guess of what is and isn't expensive. Very few servers have modes where STATUS is more expensive than open connections. NOOPs may also be expensive but a client would be foolish to assume that NOOPs will be resource intensive. (The spec merely says it is the "preferred method to do" "a periodic poll for new messages or message status updates".) The performance of STATUS or NOOP or extra connections is a quality-of-server implementation issue. If clients require fast STATUSes, people will select servers that give them that. If clients require hundreds of simultaneous connections to a single server, people will select servers that give them that. Larry
