<div class="gmail_quote">On Fri, Aug 14, 2009 at 4:06 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></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>
><br>
> I feel like redirects add unnecessary complexity.<br>
><br>
> We're already asking application developers to handle ACKing, keep<br>
> alives, multi-plexing, connection limiting, authentication, etc<br>
> themselves. To me, it doesn't seem like much of an additional burden to<br>
> ask them to handle redirects. And by keeping the spec simple, I think<br>
> we'll increase the chances of quick adoption by UAs, which will speed up<br>
> the adoption by web apps, which will give us feedback on what features<br>
> 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'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's better to not have anything at all rather than have something that's half-baked. I whole-heartedly agree that these features should be in v2.</div></div>