On Wed, Jul 20, 2011 at 3:50 PM, Matthew A. Miller < [email protected]> wrote:
> If a server is sending (in)frequent keepalives, and the client knows it > should have them (more) less, then this protocol allows for that to be > opted-in on a per-connection basis. > Both servers and clients should use as infrequent keepalives as their network and local network policy allows, and the other side shouldn't need to ask the other side to send keepalives *more* frequently. It almost seems you're suggesting a service should effectively run a > separate connection manager for each variant of > device/platform/network/solar activity/phase of moon/etc. That doesn't > sound very scalable to me. > (I said nothing of the sort.) Sending at the same rate usually means each end will detect a stale > connection at roughly the same time. That's a Good Thing™. > I don't see any significant problem if one side detects a disconnection more quickly than the other; it's going to happen anyway. With any reasonable keepalive interval, they're likely to be many minutes apart anyhow, and the common causes of disconnections are always going to be asymmetric (losing a WiFi/mobile connection; a PC crashing). As Ben stated, it's an optional feature; if you don't want it, don't use it. > "Add everything under the moon; it's okay since it's all optional" is no sane development strategy. Also, I'm not sure what you mean by "stalled". XEPs -0124 and -0206 are > DRAFT, updated with implementation experience. Are you suggesting we should > progress them to FINAL, or do you have a specific set of problems that need > immediate attention? > I gave a detailed, specific list of feedback several months ago. I received no (editorial) reply. http://mail.jabber.org/pipermail/bosh/2011-May/000380.html -- Glenn Maynard
