<div class="gmail_quote">On Fri, Aug 14, 2009 at 4:06 PM, Ian Hickson <span dir="ltr">&lt;<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Sun, 9 Aug 2009, Jeremy Orlow wrote:<br>
&gt;<br>
&gt; I feel like redirects add unnecessary complexity.<br>
&gt;<br>
&gt; We&#39;re already asking application developers to handle ACKing, keep<br>
&gt; alives, multi-plexing, connection limiting, authentication, etc<br>
&gt; themselves.  To me, it doesn&#39;t seem like much of an additional burden to<br>
&gt; ask them to handle redirects.  And by keeping the spec simple, I think<br>
&gt; we&#39;ll increase the chances of quick adoption by UAs, which will speed up<br>
&gt; the adoption by web apps, which will give us feedback on what features<br>
&gt; web developers actually want much quicker.<br>
<br>
</div>The use case for redirects is if Google (say) provides a WebSocket service<br>
that lots of sites around the Web uses, and then Google wants to move the<br>
service to another host, without transparent redirects, all the pages<br>
using the service will break until they can be updated, whereas with<br>
redirects, we can just redirect and be done with it.</blockquote><div><br></div><div>Or the protocol Google (or anyone else) creates to transport the data can support this.  If an application has to deal with ACKs, it&#39;s only a small jump to insist it also handles the initial negotiation (authentication, redirects, etc) itself.</div>

<div><br></div><div>This is why I think it&#39;s better to not have anything at all rather than have something that&#39;s half-baked.  I whole-heartedly agree that these features should be in v2.</div></div>