<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for Dave Cridland</title><link>http://disqus.com/people/a33619d2388462268ea2d2517762cb81/</link><description></description><language>en</language><lastBuildDate>Thu, 03 Jul 2008 06:43:22 -0000</lastBuildDate><item><title>Re: An Introduction To IMAP IDLE: Why Yahoo!&amp;#8217;s iPhone Push System Isn&amp;#8217;t Working So Well</title><link>http://danielrm26.disqus.com/an_introduction_to_imap_idle_why_yahoo8217s_iphone_push_system_isn8217t_working_so_well/#comment-4354781</link><description>The 3-minute timeout on IDLE is probably due to a more broken than usual NAT system on your mobile network. A good network shouldn't be timing out connections, and even a poor one should manage more than three minutes.&lt;br&gt;&lt;br&gt;And P-IMAP is a dead I-D, pushed by Oracle, which ended up being cherry-picked for value for Lemonade, which does use IDLE, and is deployed, as well as being an IETF Proposed Standard.&lt;br&gt;&lt;br&gt;Now. Your article suggests that IDLE is inherently un-robust - not true. The issue is that with a NAT in the way, a TCP connection may be severed for no good reason. TCP survives the lower layer dropping out just fine. From a technical standpoint, then, a TCP connection running dormant is the ideal solution. There's nothing magical about using TCP and IDLE to provision push notifications, as compared to some other method.&lt;br&gt;&lt;br&gt;Microsoft's solution relies on repetitive HTTP queries, which cost battery power, and, for many users, actual real money. It's still client provisioned, it's just much worse.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Cridland</dc:creator><pubDate>Wed, 11 Jul 2007 19:41:13 -0000</pubDate></item><item><title>Re: Why Identi.ca is important</title><link>http://times.disqus.com/why_identica_is_important/#comment-805628</link><description>Microblogging isn't important, but that belies the point. It's also not "better" than IRC, or XMPP - I've argued that microblogging and XMPP should converge for some time, and I think that they probably will.&lt;br&gt;&lt;br&gt;But then, I've also argued that microblogging is simply the latest incarnation of the telnet talkers of old - and those were powerful communities, too. These are not "change the world" technologies, and anyone arguing that is probably somewhat deluded - but they are pleasant, and occasionally useful.&lt;br&gt;&lt;br&gt;Dave.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Cridland</dc:creator><pubDate>Thu, 03 Jul 2008 06:43:22 -0000</pubDate></item><item><title>Re: An Introduction To IMAP IDLE: Why Yahoo!&amp;#8217;s iPhone Push System Isn&amp;#8217;t Working So Well</title><link>http://drm.disqus.com/an_introduction_to_imap_idle_why_yahoo8217s_iphone_push_system_isn8217t_working_so_well/#comment-11162530</link><description>The 3-minute timeout on IDLE is probably due to a more broken than usual NAT system on your mobile network. A good network shouldn't be timing out connections, and even a poor one should manage more than three minutes.&lt;br&gt;&lt;br&gt;And P-IMAP is a dead I-D, pushed by Oracle, which ended up being cherry-picked for value for Lemonade, which does use IDLE, and is deployed, as well as being an IETF Proposed Standard.&lt;br&gt;&lt;br&gt;Now. Your article suggests that IDLE is inherently un-robust - not true. The issue is that with a NAT in the way, a TCP connection may be severed for no good reason. TCP survives the lower layer dropping out just fine. From a technical standpoint, then, a TCP connection running dormant is the ideal solution. There's nothing magical about using TCP and IDLE to provision push notifications, as compared to some other method.&lt;br&gt;&lt;br&gt;Microsoft's solution relies on repetitive HTTP queries, which cost battery power, and, for many users, actual real money. It's still client provisioned, it's just much worse.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Cridland</dc:creator><pubDate>Wed, 11 Jul 2007 19:41:13 -0000</pubDate></item></channel></rss>