Fallback to XHR in TTAPI?

[benschumacher]

Hey-

I was trying to use TTAPI on my network and it looks like there's a transparent proxy that's causing me headaches. I realize I can use a variety of means to work around this issue, but I also noticed that the Turntable's app falls back to using an XmlHttpRequest-based mechanism when these issues are encountered.

Is it possible to do the same in the TTAPI code? I'm trying to use the JavaScript version -- haven't spent much time looking at Ruby or Python.

Thanks!

[Izzmo]

XmlHttpRequest is a browser based http request. The WebSocket class used in TTAPI will get down to this basic level of a connection if everything else fails.

[benschumacher]

In my experience, it doesn't appear that the WebSocket class handles errors in such a way that it'll fallback to a poll-based mechanism. I've observed (via packet dump) a transparent proxy on my network returning a '504 Gateway Timeout' which ultimately leads to a complete failure in the TTAPI code -- it never attempts any other type of communication after encountering that error.

I haven't dug around in the WebSockets code enough to see if it should fallback -- I just assumed it didn't. I'll spend a little more time looking into this on my end, but would appreciate any guidance.

[Izzmo]

My provider did not, at first, offer WebSockets, and thus it had to use long-polling (XHR) requests for all my bots, but I never updated the WebSocket class initially, and it all ran well. That is my only example of it working correctly and dropping down to XHR if WebSockets do not exist.

I didn't really look into it all that much though.