On Fri, Oct 12, 2012 at 11:23 AM, Michael Weibel <[email protected]> wrote: > Hi, > >> >> How would we handle fallback? I suppose that's a good topic to discuss >> in the meeting, but it would also be good to know what our options are >> (e.g., how do you discover the WebSocket endpoint in the first place >> and how do you discover that you can fall back to BOSH?). XEP-0156 >> might be relevant here. > > we're currently doing this manually, i.e. we're giving our javascript client > both endpoints and this one looks if WebSockets are available in the browser. > When WebSockets are available it connects to the WebSockets endpoint. If he > can't connect successfully after some time it will fallback to BOSH. > > This works not too bad although it could be improved more. > > What I'm wondering is: Could it be possible that you first connect to BOSH > and afterwards check if Websockets is available and somehow upgrade the > current connection? > This would speed up the whole process I guess while being still quite stable > and reliable. >
Or if you care about user experience more than server load, just initiate both connections, and pick the first one to succeed :) > Btw. someone (don't know him) published an article about Sock.js vs. BOSH: > http://mrjoes.github.com/2012/10/11/sockjs-ejabberd.html > > It might be not 100% related but still might help in the discussion. > > - Michael > -- Waqas Hussain
